ผมเคยเล่าถีง SecureSphere Web Application Firewall ไปบ้างแล้ววันนี้ผมก็อยากมาขยายความถึงความ

สามารถของมันในการปกป้องฐานข้อมูลของเว็บไซต์ของคุณ SQL Injection เป็นการโจมตีที่ได้รับความนิยมมากที่สุด

วิธีหนึ่งที่ Attacker ใช้ขโมยข้อมูลบุคคลหรือข้อมูลที่เป็นความลับของเว็บไซต์ใดๆ โดยการใส่คำสั่งในการเข้าถึงฐาน

ข้อมูล (Database) หรือที่รู้จักกันว่า “SQL Query” ไปยังช่องโหว่ของเว็บไซต์ใดๆ ทำให้ Attacker นั้นมีสิทธิ์ในการ

เข้าถึงและจัดการข้อมูลทั้งหมดใน database ของคุณได้ทันที

พวก Perimeter Firewall, IPS รวมทั้งเทคโนโลยี Web Application Firewall ที่จะพยายามวิเคราะห์และ

ตรวจจับ SQL Injection โดยเทียบกับทางฐานข้อมูล signature ที่มีอยู่ซึ่งจะดูรูปแบบของข้อมูลภายใน Web Traffic

Flows ว่าตรงบกับ signature ใดๆไหม เพื่อจะระบุว่าเป็น SQL Injection และบล็อกข้อมูลนั้น แต่ก็โชคไม่ดีเลยเพราะ

จากการทดสอบจริงๆแล้วทำให้มั่นใจได้เลยว่าแค่ signature อย่างเดียวนั้น ไม่คณามือ Attackers เลยจริงๆ

SQL Injection

            การโจมตีโดยการยิงคำสั่ง SQL เข้าไปยังเว็บใดๆนั้นจะทำให้เห็นถึงข้อมูลเกี่ยวกับ Database ข้อดีของมัน

คือใช้เพื่อตรวจสอบหาช่องโหว่ในการใส่ค่า Input ในพวก User Interface ของเว็บไซต์ (website) ในทางทฤษฎี

เว็บไซต์ควรมีการตรวจสอบทุกค่าที่ป้อนเข้ามาก่อนจะส่ง query นั้นไปยัง database แต่ถ้าการตรวจสอบ input นั้น

ไม่ได้สมบูรณ์ทุกอันหรือทุกๆ input ที่เข้ามา (อาจมีเป็นร้อยเป็นพันเลยก็ได้) ล่ะ Attacker อาจจะเปลี่ยนแปลงบาง

ส่วนของ web request (ส่วนใหญ่ก็พวก URL parameter) เพื่อให้สามารถ query ข้อมูลจาก database ได้ ผลของ

การ query จะถูกแสดงในส่วนของ HTML response ซึ่งสร้างเว็บไซต์นั้น มาลองดูตัวอย่าง SQL Injection แบบง่ายๆ

กันดีกว่าครับ โดยเราจะลองโจมตีเว็บเกี่ยวกับสุขภาพเว็บหนึ่ง

ในเว็บนี้จะมีการแสดงหมายเลขประกันสังคมของสมาชิกในครอบครัวโดยอ้างอิงจากเพศด้วย URL

http://www.superhealth.com/show_members.asp?sex=m

หลังการส่ง query นี้ไปยัง database แล้ว Web Application จะมองว่าเป็นคำสั่งดังนี้

select SSN, NAME from PATIENTS where FAMILY = XXX and sex = ‘m’

โดย XXX จะหมายถึงชื่อของครอบครัวที่เอามาจากการล็อกอินฐานข้อมูล ถ้าเว็บนี้ไม่แข็งแรงต่อการ SQL Injection

บนพารามิเตอร์ sex แล้วจะทำให้ Attacker สามารถจัดการเว็บนี้ได้อย่างง่ายได้ด้วยการ injection คำสั่งเข้ามา เช่น

http://www.superhealth.com/show_members.asp?sex=m’ or 1=1 or ‘1’=’1

เมื่อส่ง URL นี้ไปยัง database แล้วจะเกิดผลอะไรบ้าง คือมันจะมีการ query โดยคำสั่ง

select SSN, name from patients where family = xxxxxx and sex = ‘m’ or 1=1 or ‘1’=’1’

ซึ่งคำสั่งนี้จะทำให้มีการแสดงข้อมูลของคนไข้ทั้งหมดในฐานข้อมูลออกมา แล้วแสดงไปยัง Attacker

SQL Injection นั้นสามารถทำให้ได้มาซึ่ง username เป็นพันๆได้ในการโจมตีเพียงครั้งเดียวเลย ทำให้มันเป็นหนึ่ง

ในภัยคุกคามที่อันตรายที่สุดเกี่ยวกับการขโมยข้อมูลของ web application เลยทีเดียว

การป้องกัน SQL Injection ด้วย Signature

            กระบวนการในป้องกันด้วย signature นั้น คือ ตัวอุปกรณ์ต่างๆ ไม่ว่าจะเป็น Firewall, IPS จะคอยตรวจดู

traffic ใน network โดยจะมองหา text string หรือข้อความใน packet ที่เหมือนกับ signature แล้วอุปกรณ์เหล่านั้น

จะมองว่าเป็น Attack โดยส่วนใหญ่แล้ว String จะเป็นรูปแบบของ SQL Injection เช่น “or 1=1” แบบนี้เป็นแบบเบสิก

ที่ Attacker ใช้กัน ดังนั้นมันก็จะ match กับ signature ที่มีอยู่ ฐานข้อมูลของ signature ส่วนใหญ่จะเป็นโจมตีอย่าง

ง่ายๆ รูปแบบทั่วๆไปเท่านั้นถึงมันจะระบุได้ว่าเป็น attack แต่เมื่ออุปกรณ์รู้แล้ว คุณคิดว่ามนุษย์อย่าง Attacker จะไม่รู้

หรอว่ารูปแบบง่ายๆจะถูกตรวจจับได้ ก็ทำให้พวกเขาพัฒนาความเก่งกาจขึ้นตาม 5555

การหลีกเลี่ยงเพื่อไม่ให้ match กับ signature อย่างง่ายๆ

            Attacker ส่วนมากจะใช้เทดนิคอย่างง่ายๆเพื่อหลืกเลี่ยง signature แล้วปูทางไปสู่การใช้เทคนิคขั้นโปร

บุกต่อไป มาดูวิธีที่ง่ายๆกัน สัก 2-3 วิธี

1)    การเข้ารหัส(Encoding)

            เทคนิคนี้ถ้าลองไปดูประวัติการโจมตีต่างในเกี่ยวกับคอมพิวเตอร์จะเห็นว่าต้องมีเทคนิคนี้ เหตุผลที่

มีการใช้แบบนี้กันมากเพราะบางอุปกรณ์ล้มเหลวกับการถอดรหัส(Decoding), บางตัวอาจถอดรหัสได้แต่ไม่

สามารถทำแบบ real time ได้ เทคนิคการเข้ารหัส เช่น URL Encoding, UTF-8 บ่อยครั้งที่เทคนิคพวกนี้จะ

ใช้ซ่อน attack จากการป้องกันแบบ signature ได้

2)    การใช้ช่องว่าง (White Spaces Diversity) 

            signature ที่ใช้ป้องกัน SQL Injection หลายรูปแบบจะใช้วิธีแยก expression ด้วยช่องว่าง มันก็

ง่ายเลยที่จะเกิด false positives จำนวนมากถ้ามันแยกไม่เจอคำอย่าง SELECT ที่ match กับ signature

ชัวๆเลย แต่ก็มีการที่จะหลีกเลี่ยงได้เหมือนกันถ้า signature นั้นไม่ระวังมากนัก  Attack อาจหลบการตรวจ

เจอได้โดยแทนที่ 1 ช่องว่างหรือการกด spacebar 1 ครั้ง ด้วยการใส่ 2 ช่องว่าง หรือ 1 ช่องว่าง+กด tab 1 ครั้ง

3)    การแบ่งเป็นส่วนย่อยๆ ของ IP และ TCP

            เป็นเทคนิคการเลี่ยง signature อีกวิธีหนึ่ง ที่จะซ่อนการโจมตีไม่ให้ match กับ signature โดย

การแบ่งข้อความ(string) ใส่ลงไปในหลายๆส่วนย่อยของ packet

เทคนิคการเลี่ยง Signature แบบ advance

            เมื่อได้ลองเทคนิคข้างบนมาแล้วแต่ไม่ประสบความสำเร็จเลย attacker ก็จะเปลี่ยนมาใช้เทคนิคขั้นสูงขึ้น

เพื่อเลี่ยงฐานข้อมูลของ signature เราก็มาแนะนำขั้นที่สูงขึ้นหน่อย มาลองดูกัน

1)    การเลี่ยง signature สำหรับ OR 1=1

            SQL Injection ที่ทุกคนเคยใช้กันอย่าง “or 1=1” นั้น อย่าคิดเลยว่าจะไม่มี signature มาจับมัน

เป็น attack ที่ถูกจับมากที่สุด แต่ก็โชคร้าย (หรือโชคดีสำหรับ attacker เอิ้กๆ) มันมีทริกที่มีความหมาย

เดียวกับ (equivalent) “or 1=1” อย่าง OR ‘Unusual’ = ‘Unusual’

แต่ยังไงก็ตามระบบที่ตรวจจับดีๆ ก็ยังสามารถระบุรูปแบบที่เหมือนกันแบบง่ายๆนี้ได้ ดังนั้น Attacker ก็ต้อง

หาทางเพิ่มเป็น 2 expressionเพื่อให้ดูต่างไปแต่ความหมายเหมือนเดิม อย่างการเพิ่ม N เข้าไป เช่น

            OR ‘Simple’ = N’Simple’

คำสั่งนี้เป็นการบอก SQL Server ว่า cast ค่า ‘Simple’หลัง N เป็นชนิด nvarchar แต่การเปรียบเทียบค่ายัง

เท่าเดิม แต่ยังมีวิธีที่ดีกว่านั้นโดยเราอาจแยก string ออกเป็น 2 ตัว ค่าก็ยังเท่าเดิม เช่น

            OR ‘Simple’ = ‘Sim’ + ‘ple’

วิธีนี้ก็อาจเหมือนว่าจะดีที่สุดให้ในการเลี่ยงไม่ให้ signature จับได้ แต่พวก vender สร้าง regular expression

มารับมือโดยจะมองหา “or” หรือ “=” ในข้อความแต่วิธีนี้ก็ทำให้เกิด false positive จำนวนมากเลยทีเดียว แต่

attacker ก็ไม่กลัวหา expression ใหม่ที่ให้ค่าเป็น true ก็พอมาใช้อย่าง “LIKE” ในคำสั่ง SQL ที่เป็นการเปรียบ

เทียบคำบางส่วน เช่น

            OR ‘Simple LIKE ‘Sim%’

ตัวเลือกอื่นก็มีอย่างพวกตัวดำเนินการ “>”,”<”

            OR ‘Simple’ > ‘S’

            OR ‘Simple’ < ‘X’

            OR 2 > 1

หรือ Attacker อาจใช้ “IN” หรือ “BETWEEN” statements

            OR ‘Simple’ IN (‘Simple’)

            OR ‘Simple’ BETWEEN ‘R’ AND ‘T’

เมื่อเทคนิคหลบเลี่ยงใหม่ๆถูกพัฒนาขึ้น signature ที่รองรับการโจมตีนั้นๆก็ถูกคิดค้นขึ้นตามด้วยแต่การพยายาม

เพิ่ม signature ให้ครอบคลุมทุกๆเทคนิคนั้นกลับทำให้ประสิทธิภาพของระบบลดลงและประมวลผลช้าอีกต่างหาก

และยังมีความเป็นได้หากให้ match กับ SQL Keyword หรือ Meta Character จะเกิด  false positives ดูอย่าง URL นี้

                  http://site/order.asp?ProdID=5&Quantity=4

            ก็จะเห็นว่ากระบวนการตรวจจับด้วย signature อาจจะไม่ใช่วิธีแก้ปัญหาที่ตรงนักเท่าไร

2)    การเลี่ยง signature ด้วยช่องว่าง

            หลายๆ signature จะรวมช่องว่างไปด้วย เพราะ string บางอย่าง เช่น “UNION SELECT” หรือ “EXEC SP_”

จะต้องมีช่องว่างถึงจะทำงานได้ถูกต้อง ในตอนต้นเราก็แนะนำการใช้ช่องว่างอย่างง่ายไปแล้ว แต่มันก็ควรเพิ่มเทคนิค

กันหน่อยเพื่อต่อกรกับ signature ใหม่ๆ โดยอาจไม่ใช้ช่องว่างเลยหรือเพิ่ม character อะไรเข้าไป ตัวอย่างเช่น

            …OrigText'  OR  'Simple'  =  'Simple' อาจแทนด้วย …OrigText'OR'Simple'='Simple'

จากที่แสดงข้างต้นทั้ง 2 แบบให้ค่าเท่ากันแต่แบบที่ล่างไม่มีช่องว่างทำให้หลบเลี่ยง signature ได้ แต่วิธีนี้ใช้กับ

keyword อย่าง “UNION SELECT” ไม่ได้ ไม่เช่นนั้นมันจะไม่ทำงาน ก็ยังมีวิธีที่เหมาะสมกับ keyword พวกนี้

อย่างภาษาซีถ้าเพื่อนๆเคยเขียนกันมาบ้าง ก็คงทราบว่าถ้าต้องการให้ส่วนใดของโปรแกรมไม่แสดงผลการทำงาน

หรือแค่ comment ไว้เฉยๆ ก็ใช้สัญลักษณ์เริ่มด้วย “/*” และจบด้วย “*/” วิธีนี้ก็สามารถใช้ได้กับ SQL เหมือนกัน

SELECT *

FROM tblProducts /* List of Prods */

WHERE ProdID = 5

จากความคิดนี้เราก็สามารถ Injection code ได้ดังนี้

            …&ProdID=2 UNION /**/ SELECT name …

Signature จะพยายามตรวจจับ “UNION” ที่ตามด้วยช่องว่างแล้วตามด้วย “SELECT” ก็จะทำให้ไม่สามารถจับการ

โจมตีนี้ได้ ส่วนใหญ่เคส “/**/” สามารถแทนที่ช่องว่างเพื่อหลีกเลี่ยง signature ที่ sensitive มากๆ อย่าง “SELECT”

หรือ “INSERT” SQL keyword พวกนี้จะตามด้วย 1 ช่องว่าง จากตัวอย่างข้างบน ก็จะกลายเป็น

            …&ProdID=2/**/UNION/**/SELECT/**/name…

เทคนิคนี้สามารถใช้กับ Oracle ได้ แม้ว่า Oracle นั้นจะไม่ยอมให้เว้นช่องว่างหลายๆช่องได้ แต่มันก็ยอมให้ใช้

สัญลักษณ์ comment อย่าง …OrigText'/**/OR/**/'Simple'='Simple'

ส่วนเทคนิคต่อไปเป็นการหลบเลี่ยงเมื่อมีการส่งค่าพารามิเตอร์ 2 ค่าเข้าไปใน SQL เพื่อ Login อย่างเช่น

http://site/login.asp?User=X&Pass=Y

จาก request นี้จะได้คำสั่ง query ดังนี้

SELECT * FROM Users

WHERE User='X' AND Pass='Y'

ในกรณีนี้เราสามารถใส่ comment เพื่อกำจัดไปซักพารามิเตอร์นึง แล้วใส่พารามิเตอร์อื่นเข้าไป อย่างนี้ครับ

…login.asp?User=X'OR'1'/*&Pass=Y*/='1

ก็จะ query ได้ผลลัพธ์ดังนี้

SELECT * FROM Users

WHERE User='X'OR'1'/* AND Pass='*/='1'

            SQL Keyword อย่าง “SELECT” และ “INSERT” อาจถูกทำเป็น signature แต่ก็เจอปัญหาเดียวกับ

“OR” ซึ่งก็คือ False Positive ลองคิดกันดูนะครับ ถ้าในหัวข้อ “Contact Us” ของพวกเว็บไซต์ ecommerce

ลูกค้าอาจพิมมาว่า “I have selected the product, but then had a problem.” Signature มันก็จะถูกหลอก

นึกว่าเป็นการโจมตีแต่ที่จริงแล้วไม่ใช่การโจมตีอะไรทั้งสิ้น

3)    การเลี่ยงด้วยรูปแบบของสตริง

อีกวิธีหนึ่งก็คือการแยก string ออกเป็นส่วนๆ ซึ่งสามารถทำได้หลายรูปแบบเช่นกัน แบบแรกเลยก็

กลับไปที่วิธี comment ของภาษาซี แม้ว่ามันจะไม่ทำงานเมื่อไปใช้แทนช่องว่างใน MySQL แต่มันก็สามารถ

แยกคำออกจากกันได้ เช่น

      …UN/**/ION/**/ SE/**/LECT/**/…

อีกวิธีใช้การต่อ string(string concatenation) ฐานข้อมูลส่วนใหญ่จะให้ user ใช้คำสั่ง query โดยผ่านการ

ส่ง string ไปยัง server มันก็จะง่ายๆเลยถ้าเราวิธีนี้แฝงไปในสตริงที่ส่งออกไป signature ก็จะจับไม่ได้

ตัวอย่างง่ายๆ ใน MS SQL ด้วยคำสั่ง EXEC  จะได้

                        …; EXEC('INS'+'ERT INTO…')

โดย keyword “INSERT” ถูกแยกเป็น 2 ส่วน ดังนั้น signature ก็จะไม่สามารถจับได้ ยังมีตัวอย่างอื่นๆอีกที่

คล้ายกัน คือ ใน MS SQL จะมี SP_EXECUTESQL เป็นเวอชันใหม่ของ SP_SQLEXEC ซึ่งทั้งสองนี้จะรับ string

ที่มี SQL query มา execute ทำให้ใช้วิธีนี้โจมตีได้ ในฐานข้อมูลอื่นก็พบปัญหาคล้ายๆกัน วิธีนี้ยังมีความน่าสนใจ

อีก คือ string ที่ใช้จะถูกเข้ารหัสเป็นฐาน 16 เพื่อไปรันอีกที อย่าง “SELECT” จะได้ค่าเป็น “0X73656c656374”

ซึ่งถ้าทำแบบนี้ signature ไม่มีทางตรวจเจอเลย อีกตัวอย่างที่ดีของ MYSQL อย่างคำสั่ง OPENROWSET ที่อาจ

ถูก string concatenation attack แฝงมาแม้การโจมตีนี้จะถูกพบแต่หลายอุปกรณ์ยังไม่สามารถใช้ signature

ตรวจเจอได้

ทำไม Signature เพียงอย่างเดียวถึงไม่เพียงพอ

            Signature ไม่มีประสิทธิภาพพอที่จะต่อกรกับ SQL Injection ซักเท่าไรนักจากที่ผ่านๆมา การที่พยายามสร้าง

Signature ให้ครอบคลุมทุกการโจมตีนั้นจะทำให้ยิ่งแย่ลงด้วย 2 สาเหตุ คือ performance ลดลงและเกิด false positive

1)    Performance

ภาษา SQL นั้นมีความยืดหยุ่นสูง Attacker สามารถเลี่ยง signature ได้ในหลายๆวิธี แม้ว่าเราจะมีฐาน

ข้อมูล signature เป็นร้อยๆต่อ 1 ฐานข้อมูลซึ่งทำให้มันตรวจจับการโจมตีได้ และคุณคิดหรือเปล่าว่าองค์กรแต่

ละแห่งไม่ได้มีแค่ database ชนิดเดียวแน่ๆ คราวนี้ signature ที่ไว้ detect คงเกือบพัน แล้วทีนี้ performance

(throughput & latency) ล่ะครับจะเป็นยังไง ลดลงอย่างฮวบฮาบแน่นอน คงจะไม่มีใครที่ยอมรับในเรื่องได้แน่

เลย เพราะไม่งั้นก็ต้องมาเสียค่าใช้จ่ายในการเพิ่ม performance กันอีก

2)    False Positive

อย่างใน MSSQL Server มี keyword มากมาย เช่น SELECT, INSERT, CREATE, DELETE, FROM,

WHERE, OR, AND, LIKE, EXEC, SP_, XP_, SQL, ROWSET, OPEN, BEGIN, END, DECLARE และ Meta

Characters อีก ได้แก่ ; -- + ' ( ) = > < @ แต่ลองคิดดูซิครับถ้าคำเหล่านี้ถูกนำมาใช้เป็น signature หมด

คราวนี้ข้อมูลที่ user ส่งมาจะถูกบล็อกมากกว่า attacker โจมตีเข้ามาเสียอีก มันคงแย่แน่นอก คราวนี้คุณคงต้อง

การความช่วยเหลือแล้วล่ะ

การขัดขวาง SQL Injection ด้วย SecureSphere Web Application Firewall

            การจะพิจารณาว่าพฤติกรรมที่เกิดขึ้นเป็น SQL Injection จริงๆหรือไม่นั้น อาจต้องยืนยันจากหลายๆอย่าง เช่น

ผู้ดูแลระบบคนหนึ่ง(ทำงานเต็มเวลาเพียงแค่นั่งเผ้าดูและหาว่ามี security alert อะไรเกิดขึ้นบ้าง) อาจจะสังเกตเห็นว่า IDS

แจ้งเตือนว่ามี SQL Injection เกิดขึ้นมา เขาก็ต้องไปมองหาว่ามีพฤติกรรมอะไรผิดปกติเกิดขึ้นใน database log files ถ้า

เขาเจอว่ามีกิจกรรมของฐานข้อมูลที่ผิดปกติเกิดพร้อมกับที่ signature แจ้งเตือนมา เขาก็สามารถมั่นใจว่ากำลังมีการโจมตี

เกิดขึ้น เพื่อระบุจริงว่าการแจ้งเตือนนั้นไม่ใช่ false positive นี่เป็นจุดประสงค์หนึ่งที่ SecureSphere Web Application Firewall

จะมาช่วยคุณได้ ทำให้ไม่ต้องจ้างคนมานั่งเฝ้าตลอดเวลา โดยอุปกรณ์ตัวนี้จะรวมฐานข้อมูล signature ของ IPS เข้ากับการ

เก็บข้อมูลเป็น profile (Dynamic Profiling) และความรุนแรงของการโจมตีที่พบในแต่ละ layer จะเชื่อมโยงกันโดยอัตโนมัติ

อย่างถูกต้องซึ่งการป้องกันโดย signature อย่างเดียวไม่สามารถทำได้

Advanced IPS ที่จะสามารถระบุ characters ของ SQL Injection

            SecureSphere Web Application Firewall นั้นถูกออกแบบมาเพื่อตรวจจับการรวมกันของ character ที่จะสื่อถึง

SQL Injection. ฐานข้อมูล signature เกี่ยวกับ SQL Injection ของ SecureSphere(ทุกชนิดฐานข้อมูล) จะมีการอัพเดตทุก

สัปดาห์โดยทีมวิจัยของ Imperva (The Application Defense Center, ADC) ถ้าเพื่อนๆ ยังจำได้จากตัวอย่างแรกๆเลย การ

โจมตีแบบเบสิกอย่าง “or 1=1” SecureSphere IPS จะบล็อกทันทีไม่ไต่ถามใดๆทั้งสิ้น แต่ถ้าเป็นเทคนิคการเลี่ยง signature

แบบต่างๆนั้น SecureSphere จะอาศัยจากประสบการณ์ของมัน โดยขั้นแรก SecureSphere จะ apply signature ที่จำเป็นและ

ไม่มากจนเกินไปนัก อย่างการเลี่ยงจาก signature “or 1=1” ด้วย “Unusual = Unusual” ภัยคุกคามอันนี้จะถูกระรุได้โดย

SecureSphere IPS signature จะมองหาการใช้ “or” และ “=” ร่วมกัน ภายใน URL parameter และ Signature Violation

ก็จะแจ้งเตือนขึ้นมา แต่ถ้า “or” และ “=” เป็นคำทั่วๆไปใน parameter การ match บน signature นี้จะไม่ถูกบล็อกแต่อาจเกิด

false positive เป็นบางครั้ง SecureSphere จะเก็บข้อมูลการใช้งานเพื่อเป็นหลักฐานไว้ใน Dynamic Profiling

Dynamic Profiling ที่จะสามารถระบุพารามิเตอร์ที่ผิดปกติได้

            เทคโนโลยี Dynamic Profiling ของ SecureSphere จะพิจารณา traffic อย่างอัตโนมัติแล้วสร้าง เป็น “profile” ของ

ไซต์นั้นๆ โดยจะระบุแต่ละองค์ประกอบไว้ในโปรไฟล์ อาทิเช่น URLs, HTTP methods, Cookies, Parameter names,

Parameter lengths, Parameter types และอื่นๆ Profile จะทำการเก็บค่าเมื่อมีการใช้งาน Application และ SecureSphere

นั้นสามารถตรวจจับพฤติกรรมการใช้งานเว็บไซต์และเข้าถึงฐานข้อมูลที่ผิดปกติได้ ดังนั้นเมื่อมีการใช้งานเว็บไซต์มากขึ้น

SecureSphere จะมีอัลกอริทึมในการเรียนรู้และอัพเดตค่าที่เก็บในโปรไฟล์อัตโนมัติโดยเทียบจากพฤติกรรมส่วนใหญ่ที่ใช้เว็บไซต์

นั้นๆ และเรายังสามารถปรับค่าเองได้ด้วยถ้ามันเป็น false positive อย่างที่ผมได้ยกตัวอย่างในตอนแรกสุดเลยเกี่ยวกับเว็บเกี่ยวกับ

สุขภาพที่ต้องมีการส่งค่าพารามิเตอร์ sex ซึ่งอาจถูก SQL Injection ได้ เช่น “OR Unusual = Unusual” แต่เรารู้ว่า sex มีการส่ง

ค่าเพียง 1 ตัวอักษร ถ้าเรากำหนดได้เราก็จะป้องกันการโจมตีนี้ได้ มาดูความสามารถของ SecureSphere Dynamic Profile กันครับ

คราวนี้เมื่อเราจำกัดตัวอักษร(มันเรียนรู้เองอะ เราไม่ต้องไม่กำหนดมัน แต่เราแก้ไขได้) ได้แล้ว ถ้ามีการยิง SQL เข้ามาจะเกิดอะไรขึ้น!!!

SecureSphere Parameter Length Violation Alert ก็จะแจ้งเตือนดิครับ

ยังมีตัวอย่างของไซต์ที่มีการใช้งานจริงอีกด้วย เชิญดูครับ

Dynamic Profile ยังใช้ในการตรวจสอบการโจมตีโดยถ้ามีเหตุการณ์ใดเกิดจาก user คนเดิมซ้ำๆกัน จะทำให้อีกความสามารถ

ของ SecureSphere คือ SecureSphere’s Correlated Attack Validation ทำงาน

Correlated Attack Validation (CAV)

            โดย CAV จะเชื่อมโยงการโจมตีหรือ Violation ต่างๆที่เกิดขึ้นจาก user คนเดียวกันที่ข้ามผ่านด่านความปลอดภัยเข้ามาได้

(IPS, Dynamic Profile ฯลฯ) ถ้า user คนหนึ่ง attack แบบเดิมๆหลายๆครั้ง เราก็จะมั่นใจได้เลยว่าเขาตั้งใจจะโจมตีจริงๆ จากตัวอย่าง

CAV เชื่อมโยง SQL signature violation กับ Parameter length violation เพื่อตรวจว่าเป็นการโจมตีแบบจริง ทำให้ CAV สามารถ

ช่วยระบุการโจมตีได้อย่างแม่นยำยิ่งเมื่อมีการใช้เทคนิคในการเลี่ยง signature ขั้นสูง มันก็จะเชื่อมโยงทุก violation ที่เกิดขึ้นแล้วระบุ

ไปยัง user คนที่โจมตีมาได้

Conclusion

1)    SQL Injection คือ การใส่หรือแฝงคำสั่ง SQL เข้าไปใน HTTP request ที่จะส่งไปยัง Server เพื่อทำการ query, insert,

delete หรือใดๆ กับฐานข้อมูล

2)    การเลี่ยงไม่ให้ SQL Injection ไป match กับ signature แบบง่ายๆ มี 3 แบบที่ได้แนะนำไป คือ การเข้ารหัส การใช้ช่องว่าง
และการแบ่งออกเป็นส่วนย่อยๆของ IP และ TCP ส่วนการเลี่ยงแบบขั้นสูงอาจใช้คำสั่งที่มีความหมายเหมือนกันแต่คนละรูปแบบ
การใช้การต่อสตริง(string concatenation) การใช้คอมเม้นท์ที่ใช้ในภาษาซี เป็นต้น

3)    การใช้ Signature Mechanism ไม่เพียงพอต่อการป้องกัน SQL Injection เพราะการโจมตีมีการพัฒนาอยู่เรื่อยๆ ถ้าต้องการให้
ครอบคลุมทุกการโจมตีจะต้องเพิ่ม signature เข้าไปจำนวนมากทำให้เกิดข้อเสียอีก 2 ข้อใหญ่ คือ ทำให้ Performance ลดลง
และ เกิด False Positive จำนวนมาก

4)    การป้องกัน SQL Injection บน SecureSphere Web Application Firewall โดยใช้ Advanced IPS, Dynamic Profiling และ
Correlated Attack Validation ทำให้มีประสิทธิภาพในการป้องกันและเกิด false positive น้อยมาก

ผมคิดว่าบทความนี้คงทำให้เพื่อนได้รู้จักการโจมตีที่เรียกว่า “SQL Injection” มากขึ้น รวมถึงวิธีที่ Attacker นิยมใช้ พร้อมทั้ง

หนทางที่จะป้องกันอันตรายจากภัยนี้เพื่อให้องค์กรมีความปลอดภัยมากขึ้นนะครับ แล้วเจอกันใหม่นนะค้าบบ