คลังเก็บหมวดหมู่: Security

Laravel 4 Security

เขียนบน โดย
1

จากเมื่อก่อนที่เคยเขียน Laravel Security ซึ่งในตอนนั้นผมยังใช้ Laravel 3 อยู่ แต่ทุกวันนี้ต้องบอกเลยว่า Laravel 4 นั้นเยี่ยมมากๆ และยังไม่รวมถึง Laravel 4.1 ที่ดีขึ้นไปอีก แต่ขั้นตอนการ update ออกจะสะท้านหน่อยในโปรเจ็คขนาดใหญ่

วันนี้ผมจะเขียนอิงหัวข้อเดิม จะได้เป็นข้อเปรียบเทียบกับ Laravel 3 ได้เพื่อใครที่กำลังตัดสินใจว่าจะใช้ดีหรือไม่ โดยผมจะเขียนอิง Laravel 4 ซึ่งในด้านความปลอดภัยนั้นไม่ได้แตกต่างกับ 4.1 สักเท่าไร

1. CSRF protection หรือการปลอมแปลง http request ที่เรียกข้ามเว็บไซต์ เรื่องนี้ Laravel มีป้องกันอยู่แล้ว โดยเป็นการสร้าง Token ไว้ตรวจสอบ หาอ่านได้ที่ CSRF protection แต่สำหรับคนที่เขียน Route แบบ Controller สามารถเขียน filter ไว้ที่ Controller แบบนี้ได้ (ไม่มีใน doc)

$this->beforeFilter('csrf');

2. Cookie Security เรื่องนี้ไม่ต่างจาก Laravel 3 มากครับ หาอ่านได้ที่ Cookies ซึ่งจริงๆ ต้องบอกรวมๆ ว่าข้อมูลต่างๆ ของ Laravel 4 ทั้ง Cookie Session จะถูกเข้ารหัสทั้งหมด ทำให้ข้อมูลนั้นปลอดภัยครับ แต่ถ้าเรื่องทางเทคนิคเชิงลึก แนะนำให้แกะโค้ดดูครับ

3. SQL-Injection เรื่องนี้ไม่ต้องท้าวความเลย มีป้องกันไว้เหมือนกัน โดย Laravel จะทำงานผ่าน PDO หาอ่านได้ที่ PDO/Prepared statements and stored procedures สรุปให้สั้นๆ คือ ถ้าเรียกทำงานผ่าน Fluent หรือ Eloquent มันก็จะจัดการให้เสร็จ ซึ่งใน Laravel 4 ยังสามารถเขียน query ดิบได้อยู่ แต่มันเป็นสิ่งที่ไม่แนะนำให้ทำครับ เราจึงไม่เห็นหัวข้อของเรื่อง raw query ถูกพูดใน doc ซักเท่าไร (ถูกให้ความสำคัญลดลง)

4. XSS หรือการแทรกโค้ดไม่พึ่งประสงค์ลงหน้าเว็บ เรื่องนี้ Laravel ไม่มีการป้องกันครับ เหมือนเดิมครับ เพราะ PHP ก็มีฟังค์ชั่นพื้นฐานมาเพื่อป้องกันเรื่องพวกนี้แล้วอย่าง strip_tags() and htmlentities() ดังนั้นเรื่องนี้ต้องจัดการกันเองครับ ด้วยการเขียน Validation ให้ครบครับ

เขียนคราวนี้เหมือนเอาบทความเก่ามาแก้ครับ เพราะช่วงนี้งานชุกครับ  /XD

งานวิจัยเผย SSL มีความเสี่ยงต่อการแฮกเมื่อไม่ได้ใช้งานผ่านเว็บเบราว์เซอร์

เขียนบน โดย
ตอบกลับ

คงไม่มีใครปฏิเสธได้ครับว่า SSL คือเทคโนโลยีหนึ่งที่สำคัญมากแบบขาดเสียไม่ได้ ทั้งในด้านธุรกรรมการเงิน การส่งต่อข้อมูลความลับต่างๆ ซึ่งเหตุผลหลักคือเพื่อป้องกันการโจมตีจากเหล่าบรรดาแฮกเกอร์ แต่เมื่อไม่นานมานี้ได้มีการเปิดเผยว่า SSL เมื่อถูกใช้งานในบางสถานการณ์นั้นอาจไม่ปลอดภัยอย่างที่เคยคิดกัน

เมื่อไม่นานมานี้ได้มีงานประชุม ACM Conference on Computer and Communications Security (CCS2012) ที่จัดเสร็จสิ้นในวันที่ 16-18 ตุลาคมที่ผ่านมา ซึ่งเป็นงานรวมตัวของนักพัฒนาโปรแกรม ผู้เชี่ยวชาญด้านความปลอดภัยทั้งจากภาครัฐ สถานศึกษา และเอกชน ได้เข้ามานำเสนอถึงทฤษฎีหรืองานวิจัยต่างๆ โดยหลังจากจบงานและเปเปอร์งานวิจัยต่างๆ ได้ขึ้นเว็บแล้วที่เว็บของ CCS 2012

ในงานนี้ได้มีงานวิจัยชิ้นหนึ่งที่สำคัญมาก ซึ่งจัดทำโดยนักวิจัยจากมหาวิทยาลัยเทคซัสในเมืองออสตินและมหาวิทยาลัยสแตนฟอร์ด ได้ระบุว่า SSL ที่ไม่ได้มีการใช้งานผ่านเว็บเบราว์เซอร์มีความเสี่ยงจะถูกโจมตีแบบ man-in-the-middle attack ได้ (อ่านคำอธิบายเพิ่มได้ที่ท้ายข่าว) โดยการใช้งานที่ไม่ได้ผ่านเว็บเบราว์เซอร์ ในงานวิจัยได้ยกตัวอย่างดังนี้

  • JAVA library ของ Amazon EC2
  • SDK ระบบซื้อขายของ Amazon และ Paypal (เฉพาะ Paypal นี้ SDK จะถูกใช้เชื่อมกับ osCommerce, ZenCart, Ubercart และ PrestaShop)
  • AdMob ผู้ให้บริการโฆษณาบนมือถือ ที่ Google เป็นเจ้าของ
  • ระบบ Mobile Banking ของ Chase.com
  • โปรแกรมสำหรับทำ web service ที่เขียนด้วยภาษา JAVA รวมถึง Apache Axis, Axis 2,
  • Codehaus XFire, และ Pusher library สำหรับ Android
  • รวมถึงโปรแกรมอะไรก็ตามที่ทำหน้าที่เป็นตัวกลางในการติดต่อผ่าน SSL

อย่างไรก็ตามไม่ได้หมายความว่าโค้ดที่ถูกเขียนบนระบบที่กล่าวมาจะถูกเขียนแบบผิดพลาด ในความเป็นจริงนั้นได้เขียนถูกต้องด้วยซ้ำ แต่เพราะโค้ดดังกล่าวจะมีการติดต่อผ่านไลบรารี่ที่ใช้ควบคุมการส่งข้อมูล เช่น Apache HttpClient หรือ cURL ซึ่งปัญหาเกิดจากนักพัฒนาเกิดความเข้าใจผิดทั้งการกำหนดพารามิเตอร์หรือการตรวจสอบค่าย้อนกลับ ทำให้กระบวนการยืนยัน SSL certificate มักจะล้มเหลวในท้ายที่สุด

เท่าที่ผมอ่านงานวิจัยคร่าวๆ ขอสรุปว่าสำหรับนักพัฒนาโปรแกรมด้วยภาษา JAVA และ PHP ที่ได้มีการใช้งานระบบใดระบบหนึ่งที่ได้กล่าวถึงไปหรือมีการใช้งาน SSL ในกระบวนการติดต่อเบื้องหลัง สมควรอ่านงานวิจัยนี้เพื่อแก้ไขหรือหาทางออก เพราะในงานได้มีบอกไว้ว่าจุดใดคือความเสี่ยงครับ

งานวิจัยดังกล่าวสามารถโหลดอ่านได้ที่นี้ Full paper

ที่มา – The Applied Crypto Group of Stanford University

คำอธิบายเพิ่ม
man-in-the-middle attack เป็นการโจมตีโดยการเบี่ยงเบนการเดินทางของข้อมูลที่ควรจะเดินทางระหว่างคอมพิวเตอร์ผู้ใช้งานกับเครื่องแม่ของผู้ให้บริการ ให้เดินทางมายังเครื่องของแฮกเกอร์แทนด้วยการหลอกทั้งเครื่องผู้ใช้งานและเครื่องแม่ว่าเครื่องตัวเองเป็นเครื่องของอีกฝ่ายที่กำลังติดต่อด้วย เป้าหมายคือการดักจับข้อมูลที่ถูกเข้ารหัสไว้หรือการปลอมแปลงข้อมูลให้ผิดไปจากเดิม

บทความนี้ถูกเผยแพร่ที่ Blognone