ตรวจ security เว็บ Laravel ที่ deploy แล้ว — ไล่ 3 ชั้นตามลำดับที่ควรแก้
เว็บ Laravel ที่ deploy บน shared host หลัง Cloudflare มีจุดรั่วซ้ำ ๆ ที่ตรวจได้จากนอกภายในไม่กี่นาที — ไฟล์ .env โผล่ 200, ไฟล์ debug เปิดทิ้ง, permission หลวมจนเพื่อนบ้านอ่าน DB password ได้ ไล่เป็นชั้นแล้วแก้ตามลำดับความเจ็บ
สรุปใน 1 นาที
- อาการ/ปัญหา
- เว็บ Laravel หลัง deploy มีจุดรั่วซ้ำ ๆ เช่น .env เปิดได้ ไฟล์ debug ค้าง สิทธิ์ไฟล์หลวม
- ใครควรอ่าน
- คนที่เพิ่ง deploy Laravel ขึ้น production หรือ shared host
- ทางแก้แบบสั้น
- ไล่ตรวจสามชั้น probe จากนอก, ไฟล์และสิทธิ์บนเซิร์ฟเวอร์, grep หาช่องในโค้ด แล้วแก้ตามลำดับ P0 ถึง P2
พอดีผม 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
ค่า 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 เป็นการลดผลกระทบเวลาโดนจริง — จัดคิวให้ถูกจะไม่เสียเวลาไปขัดเงาโค้ดทั้งที่ประตูหน้ายังเปิดอยู่
สามชั้นนี้ยิงรวมกันไม่ถึงห้านาที ผมทำเป็นสคริปต์เดียวรันหลัง deploy จบทุกรอบ — ดีกว่ารอให้มีคนมาเจอช่องให้
สรุปคือความปลอดภัยของ Laravel บน production ส่วนใหญ่ไม่ได้แพ้ที่ช่องซับซ้อน แต่แพ้ที่ของพื้นฐานที่ลืม — ไฟล์ที่ไม่ควรเปิดกลับเปิด, permission ที่ตั้งหลวม, debug ที่ลืมปิด ตรวจสามชั้นนี้ให้เป็นนิสัยหลัง deploy ทุกครั้ง จะตัดปัญหาไปได้เกือบหมด ใครดูแลเว็บ Laravel หลายตัวเอาไปทำเป็นสคริปต์ประจำได้ตามสะดวกครับ ตรงไหนผมอธิบายตกหล่นหรือพิมพ์ผิด เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย