Security

ตรวจ security เว็บ Laravel ที่ deploy แล้ว — ไล่ 3 ชั้นตามลำดับที่ควรแก้

โดย Ton-Or ·17 ก.ค. 2026·อ่าน 8 นาที

เว็บ Laravel ที่ deploy บน shared host หลัง Cloudflare มีจุดรั่วซ้ำ ๆ ที่ตรวจได้จากนอกภายในไม่กี่นาที — ไฟล์ .env โผล่ 200, ไฟล์ debug เปิดทิ้ง, permission หลวมจนเพื่อนบ้านอ่าน DB password ได้ ไล่เป็นชั้นแล้วแก้ตามลำดับความเจ็บ

พอดีผม deploy เว็บ Laravel ขึ้น production บ่อย แล้วก่อนจะปล่อยให้คนใช้จริง มีชุดตรวจความปลอดภัยที่ไล่ทุกครั้ง เพราะจุดรั่วของ Laravel บน shared host มันซ้ำ ๆ กัน ตรวจจากนอกภายในไม่กี่นาทีก็เจอ เลยเรียบเรียงเป็นสามชั้น + ลำดับที่ควรแก้ไว้

ชั้นที่ 1: probe จากนอก — endpoint ที่ไม่ควรเปิด

ยิงจากเครื่องนอกเลย ดูว่าไฟล์/route ที่ไม่ควรเข้าถึงได้ ตอบ 200 หรือเปล่า

SITE=https://example.com
for p in .env .git/config .git/HEAD vendor/composer/installed.json \
         storage/logs/laravel.log _ignition/health-check _debugbar/open up; do
  code=$(curl -sk -o /dev/null -w '%{http_code}' "$SITE/$p")
  echo "[$code] /$p"
done

ตัวที่เจอแล้วต้องรีบแก้

/.env ตอบ 200 = รหัส DB/APP_KEY หลุดทั้งชุด (P0 ทันที) · /.git/config = ดึง source ทั้ง repo ได้ · /_ignition/... เคยมีช่อง RCE (CVE-2021-3129) · /_debugbar/open เปิดทิ้ง = query/ข้อมูลภายในโผล่ · /up health route เอาไว้ fingerprint ว่าเป็น Laravel เวอร์ชันไหน

ทุกตัวที่ควรปิดต้องตอบ 403/404 ไม่ใช่ 200 — ถ้า .env โผล่ นี่คือของด่วนที่สุด

ชั้นที่ 2: ไฟล์และสิทธิ์บนเซิร์ฟเวอร์

ssh เข้าไปเช็ค permission — บน shared host ค่า default มักหลวมเกินไป

cd ~/domains/example.com/laravel_app
stat -c '%a %n' .env                    # ต้องเป็น 600 ไม่ใช่ 644/664
find . -name '.env*' -perm /o+r         # .env ที่ others อ่านได้ = เพื่อนบ้านอ่าน DB pass ได้
ls -la storage bootstrap/cache          # ควร 775 เจ้าของถูกต้อง ไม่ใช่ 777
grep -n 'APP_DEBUG' .env                # production ต้อง false

กับดัก permission บน shared host

ค่า default 644/664 แปลว่า user อื่นบนเครื่องเดียวกันอ่านไฟล์เราได้ — .env ที่มีรหัส DB จึงต้อง chmod 600 เสมอหลัง deploy และ APP_DEBUG=false ไม่งั้นหน้า error โชว์ stack trace + ค่า config ให้คนนอกเห็น

ชั้นที่ 3: grep หาช่องในโค้ด

ตรวจ pattern อันตรายที่มักหลุดมาในโค้ด

# mass-assignment เปิดกว้าง
grep -rn 'protected $guarded = \[\]' app/Models/
# raw SQL ที่ต่อ string ตรง ๆ (SQL injection)
grep -rn 'DB::raw\|whereRaw\|->raw(' app/ | grep -v '?'
# echo ตัวแปรดิบใน blade (XSS)
grep -rn '{!! *\$' resources/views/
# ฟังก์ชันอันตราย
grep -rn 'eval(\|shell_exec\|system(\|proc_open' app/ routes/

{!! $var !!} ใน blade คือจุด XSS คลาสสิก (ปิด escaping) — ถ้าตัวแปรมาจาก user ต้องเปลี่ยนเป็น {{ }} หรือ sanitize ก่อน

ลำดับการแก้: P0 → P2

P0 — ปิดรอยรั่วรหัส: .env/.git โผล่ 200, permission .env หลวม, APP_DEBUG=true
P1 — ปิด hardening ที่แตก: debug endpoint เปิด, fingerprint โชว์เวอร์ชัน, security headers ไม่มี
P2 — defense-in-depth: mass-assignment กว้าง, raw SQL, XSS ในโค้ด — ไล่แก้เชิงลึก

ลำดับสำคัญตรงที่ P0 คือของที่ "เปิดประตูให้คนเดินเข้าเลย" ต้องอุดก่อน ส่วน P2 เป็นการลดผลกระทบเวลาโดนจริง — จัดคิวให้ถูกจะไม่เสียเวลาไปขัดเงาโค้ดทั้งที่ประตูหน้ายังเปิดอยู่

ทำเป็น checklist หลัง deploy ทุกครั้ง

สามชั้นนี้ยิงรวมกันไม่ถึงห้านาที ผมทำเป็นสคริปต์เดียวรันหลัง deploy จบทุกรอบ — ดีกว่ารอให้มีคนมาเจอช่องให้

สรุปคือความปลอดภัยของ Laravel บน production ส่วนใหญ่ไม่ได้แพ้ที่ช่องซับซ้อน แต่แพ้ที่ของพื้นฐานที่ลืม — ไฟล์ที่ไม่ควรเปิดกลับเปิด, permission ที่ตั้งหลวม, debug ที่ลืมปิด ตรวจสามชั้นนี้ให้เป็นนิสัยหลัง deploy ทุกครั้ง จะตัดปัญหาไปได้เกือบหมด ใครดูแลเว็บ Laravel หลายตัวเอาไปทำเป็นสคริปต์ประจำได้ตามสะดวกครับ ตรงไหนผมอธิบายตกหล่นหรือพิมพ์ผิด เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ

อยากให้เราทำให้ไหม?

ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า

คุยเรื่องงานกับเรา

แท็ก #security #hardening #php-fpm #cloudflare #ssl #debugging #sysadmin #shared-host #laravel #php #owasp #pentest #web-security #best-practices

เคยเจองานแบบนี้ไหม? ติดตรงไหน?

มาแลกวิธีกันต่อในบอร์ด LinuxThai

→ คุยต่อในบอร์ด

ความคิดเห็น 0

ยังไม่มีความคิดเห็น — เป็นคนแรกเลย