สวัสดีครับทุกคน จากที่คุณ Oak ได้แนะนำให้เพื่อนได้รู้จักับ Web Application Firewall หรือ WAF กันไปบ้างแล้ว เราลองมาดูกันว่าเจ้าตัว WAF นี้มันต่างกับ Firewall แบบเดิมๆอย่างไร ในปัจจุบันนี้ช่องโหว่ของ Web Application ก็ถูกพบมากขึ้นทุกๆวัน ก็เลยทำให้มีหลายๆ vender ที่พยายามเพิ่มฟังก์ชันให้กับ firewall ของตน อย่างเช่น Deep Packet Inspection (DPI) ที่จะเข้าไปเฝ้าระวังถึงระดับ packet กันเลยทีเดียวหรือส่วนใหญ่เราก็จะรู้จักกันในนาม Intrusion Prevention System
แต่เมื่อเอามันมาใช้งานกันจริงๆแล้ว มันก็ป้องกันได้แค่ระดับโครงสร้างทั่วไปของโปรแกรมเท่านั้น เราจะมาลองเปรียบเทียบให้ดูกันว่าไฟร์วอลล์เจ้าใหญ่ๆ อย่าง checkpoint และ netscreen และผู้ที่เชี่ยวชาญการป้องกัน Application โดยเฉพาะอย่าง Imperva โดยจะวิเคราะห์ความปลอดภัยตาม Open Web Application Security Project (OWASP) ใน 10 อันดันที่ถูกโจมตีบ่อยที่สุดจากทั่วโลก

OWASP Top Ten application security vulnerabilities
1) Unvalidated Parameters คือ ค่าที่ผู้ใช้ป้อนทาง Application แต่ไม่เป็นไปที่กำหนดไว้อาจเพื่อโจมตี Applicaiotn หรือเข้าใจผิดก็ตาม ทำให้ Attacker สามารถใช้วิธีนี้โจมตีในส่วนของ Backend ได้
2) Broken Access Control คือ การที่มีผู้ใช้งานทำการยืนยันและพิสูจน์ตัวตนอย่างไม่เหมาะสม เพื่อเข้าถึงข้อมูล
3) Broken Accent & Session Management คือ การที่บัญชีผู้ใช้งานไม่มีการป้องกันที่เหมาะสม ทำให้ Attacker สามารถขโมยรหัสผ่าน, keys, token ไปได้ ทำให้สามารถปลอมตัวเป็นผู้ใช้คนนั้นได้
4) Cross-Site Scripting (XSS) คือ กระบวนการที่เว็บไซต์ส่งการโจมตีไปยังเครื่องผู้ใช้ปลายทางผ่าน browser
5) Buffer Overflow คือ การที่ข้อมูลมีขนาดใหญ่เกินกว่ามาตรฐานที่ตั้งไว้
6) Command Injection Flaws โดยทั่วไปแล้ว web application จะมีการส่งผ่าน parameter นั่นจึงเป็นอีกช่องทางของ Attackers ที่จะแอบฝังคำสั่งอันตรายๆมากับพารามิเตอร์เหล่านั้น
7) Error Handling Problems คือ การที่เมื่อเกิดปัญหาอะไรขึ้นเครื่องเซิฟเวอร์จะแจ้งเตือนผ่าน browser ทำให้ผู้ใช้ทราบข้อมูลต่างๆได้ เช่น ใช้ IIS หรือ Apache, version อะไร เป็นต้น
8) Insecure Use of Cryptography อาจเป็นการใช้วิธีเข้ารหัสที่มีความปลอดภัยต่ำ
9) Remote Administration Flaws คือ การที่ Attackers ซึ่งไม่มีสิทธิ์ระดับ Administrative สามารถได้สิทธ์นั้นมาทำให้ Attackers ที่ได้สิทธิ์นั้นก็จะสามารถจัดการเว็บของคุณได้ทั้งหมด
10) Web & Application Server Misconfiguration เป็นเรื่องยากที่จะ config ให้ server มีความปลอดภัยมากที่สุด
Perimeter Firewall
คราวนี้มาลองดูกันว่าทั้ง Check Point และ NetScreen มี feature อะไรเพิ่มขึ้นมาบ้าง เพื่อ Web Application Security
|
Check Point Firewall -1 NG |
NetScreen |
|
วิเคราะห์ข้อมูลว่าเป็นไปตาม RFC ของ Protocol ต่างๆไหม
ตรวจสอบจาก signature หรือก็คือรูปแบบการโจมตีที่พบบ่อยๆ |
Perimeter Firewall VS TOP 10 OWASP
ต่อไปเรามาดูกันว่า Feature ที่เพิ่มขึ้นมาของ Perimeter Firewall นั้นจะช่วยป้องกันช่องโหว่จาก list ของ OWASP ได้ทุกข้อจริงหรือไม่
|
OWASP ช่องโหว่ |
ป้องกัน?? |
ทำไมล่ะ?? |
|
1) Unvalidated Parameters |
ไม่ได้ |
Firewall ไม่สามารถตรวจสอบได้ว่า Attackers เปลียนแปลง, เพิ่ม หรือลบพารามิเตอร์ตัวใด |
|
2) Broken Access Control |
ไม่ได้ |
Firewall ไม่สามารถบอกได้ว่ามีผู้ใช้คนใดพยายามจะดูข้อมูลของผู้ใช้คนอื่นๆ หรือเข้าถึงสิทธิ์ของผู้อื่น |
|
3) Broken Accent & Session Management |
ไม่ได้ |
Firewall ไม่สามารถที่จะดู session และ cookies ของ application ต่างๆได้ และไม่สามารถบอกได้ถ้ามีการเปลี่ยนแปลงตัวตนระหว่างการใช้งานsession ใดๆ |
|
4) Cross-Site Scripting (XSS) |
บางส่วน |
Firewall บางชนิดจะมีการตรวจสอบข้อมูลที่ไหลผ่านกับ signature ที่เก็บไว้เพื่อป้องกัน script ที่พบบ่อยๆ แต่ก็อาจทำให้เจอกับปัญหา false positive ได้ ส่วน false positive นี่แปลกันภาษาพื้นๆ ก็คือ สิ่งที่มันถูกต้อง แต่ตัวไฟร์วอลล์จะเตือนว่าเป็นภัยครับ |
|
5) Buffer Overflow |
ไม่ได้ |
Firewall มันไม่ฉลาดพอที่จะรู้ว่าบัฟเฟอร์ที่ถูกจองไว้สำหรับรับส่งข้อมูลจะมีขนาดพอกับข้อมูลที่มันจะรับเข้าหรือส่งออกไปหรือไม่ |
|
6) Command Injection Flaws |
บางส่วน |
อันนี้ก็เช่นเดียวกับ XSS เพราะว่าจะมีการเทียบ command ต่างๆกับ signature ที่มันรู้จัก เช่น พวกคำสั่ง SQL ทั้งหลาย อาจถูกบล็อกได้แม้ว่ามันจะเป็นคำสั่งที่จะต้องใช้งานจริงๆ ก็จะทำให้เกิดปัญหา false positives จำนวนมากอีกเช่นเคย และ Perimeter Firewall นี้ก็ไม่สามารถตรวจสอบคำสั่งที่ถูกฝังมากับ SSL ได้เลย |
|
7) Error Handling Problems |
ไม่ได้ |
Firewall อีกเช่นเคยมันก็ไม่รู้หรอกว่า server ใดๆ จะแสดง error ออกมาให้ผู้ใช้เห็น เมื่อเกิดเงื่อนไขความผิดพลาดขึ้น เช่น เมื่อเข้าเว็บไม่ได้มันก็จะแสดงว่าใช้IIS หรือ Apache |
|
8) Insecure Use of Cryptography |
ไม่ได้ |
ความแข็งแกร่งของการเข้ารหัสพารามิเตอร์(parameters) และ cookies ไม่สามารถจะถูกเช็คได้โดย Firewall ถ้ามีใครสามารถถอดรหัสพารามิเตอร์แล้วเปลี่ยนแปลงค่าและเข้ารหัสใหม่อีกครั้ง ก็เป็นอันจบ ไฟร์วอลล์ก็จะไม่รู้เรื่อง |
|
9) Remote Administration Flaws |
ไม่ได้ |
จะใช้การสร้าง Black list ขึ้นมาเพื่อป้องกันเฉพาะหน้าเว็บที่จะไม่ให้เข้าใช้โดยผู้ใช้ทั่วไป แต่เป็นไปได้ที่จะถูกโจมตีได้โดยง่าย |
|
10) Web & Application Server Misconfiguration |
บางส่วน |
โดยจะใช้ signature ในการเทียบกับการโจมตีต่างๆที่เกิดขึ้นบ่อยๆ เช่น Zero-day แต่ถ้าสมมติว่าพรุ่งนี้มีคนหาวิธีล่มเว็บได้ง่ายๆโดยส่ง URL เบสิกๆ สักอัน เช่น www.victim.com/pagex.dll?param=shutdown แบบนี้ Firewall มันก็จะปล่อยผ่านไป |
วิธีการเพิ่ม Web Application Security
เราจะเห็นได้ว่าส่วนใหญ่ที่ไฟร์วอลล์ทั่วไป ป้องกันการโจมตี Web Application ไม่ได้ เพราะมันไม่รู้ว่าแต่ละหน้าเว็บ แต่ละ URL มันมีพฤติกรรมการใช้งานอย่างไร เช่น บาง URL อาจมีการส่ง parameter เฉพาะของ URL นั้นๆ ถ้า Attacker จะพยายามแก้ไขค่าและส่งไปยัง URLใดๆ ไฟร์วอลล์ควรจะต้องตรวจจับได้ นั่นคือ การเก็บข้อมูลที่เรียกว่า Profiling และควรรวมไปถึงพวกคำสั่ง SQL ที่ติดต่อกับ Database ด้วย เพื่อจะได้มั่นใจได้ว่า Attackers ไม่ส่งอะไรแปลกๆไปยัง database เพื่อทำการมิชอบกับฐานข้อมูล
คุณรู้สึกไหมว่าถ้าบริษัทเรามี Applications เยอะๆ เราจะทำอย่างไรให้มันปลอดภัย ถ้าแค่ไม่เกิน 10 application เราก็คงสามารถมานั่งไล่ดูทีละโปรแกรมแล้วทำให้มัน secure ขึ้น หรืออาจสร้าง white list แต่มันก็เกิดปัญหาตามมาอยู่ดีนั่นก็คือ เรื่อง false Positive จำนวนมากมาย นี่ยังไม่รวมถึงพวก app ที่เชื่อมต่อกับ database นะครับ ที่นี้ใครล่ะจะมาคอยนั่งดูโค้ดว่าตรงไหนไม่ปลอดภัย ผมล่ะไม่คนหนึ่ง เหอๆๆ มึนก่อนแน่นอน เมื่อเรามีการ Profiling มันจะควรจะมีการเรียนรู้ด้วยตัวมันเองด้วยที่เรียกว่า Self Learning Capabilities ทำไมล่ะ? เพราะว่าเมื่อมี URL ใหม่ หรือ SQL queries ที่ถูกเพิ่มเข้ามามันจะเรียนรู้เองแบบ dynamic ได้ และถ้าให้ดีควรจะมีการตรวจดูว่าเมื่อมีคนเข้ามา ใช้งาน Application แล้วเขามีการใช้งานเป็นอย่างไร มีการส่งพารามิเตอร์อะไรบ้าง แล้วถ้าเขาเข้ามาใช้งาน App อีกมีการใช้งานผิดไปจากที่เคยใช้หรือเปล่า และก็ควรสามารถบล็อกการใช้งานที่ผิดแปลกไปจากเดิมได้ในทันที แต่ก็คงต้องมีการให้มันเรียนรู้การใช้งานของผู้ใช้สักพักอ่ะนะ แล้วมันก็จะเป็น Firewall ที่ฉลาดขั้นเทพเลย 555 แถม web admin ก็สบายไม่ต้องมานั่งทำ White list อีก, developer ก็สบายด้วยเพราะแม้ว่า code ที่เขียนมานั้นจะไม่ secure เอาซะเลยมันจะเรียนรู้และบล็อกได้ ถ้า Developer ว่างๆ ก็ค่อยมาแก้ให้มัน secure ขึ้นก็ได้
ผมคงต้องไปทำงานก่อนนะครับ แล้วจะมาต่อกันตอน 2 ว่าไอ้ที่ Perimeter Firewall ไม่สามารถป้องกัน Web Application ได้นั้น SecureSphere ของ Imperva จะช่วยป้องกันได้ในระดับไหน แล้วเจอกันค้าบ







I view commenting as a
I view commenting as a continuation of the blog post itself. It can either add or dispute the post, or answer a question. Therefore, it's possible to purchase or buy essays that will be superb.
คอมเม้นท์ไม่ได้อ่ะ
คอมเม้นท์ไม่ได้อ่ะ
น่าสน
น่าสน
Post new comment