Call Us Now: 0-2530-2062-4

SQL Injection และเทคนิคการหลบหลีกการตรวจจับ

ผมเคยเล่าถีง 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 คนที่โจมตีมาได้

บทสรุป

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 นิยมใช้ พร้อมทั้งหนทางที่จะป้องกันอันตรายจากภัยนี้เพื่อให้องค์กรมีความปลอดภัยมากขึ้นนะครับ แล้วเจอกันใหม่นนะค้าบบ

Leave a Reply

Address

BizTown LatPhrao
2521/7 LatPhrao Road, Wangthonglang, Bangkok 10310 Thailand
Phone: 0-2530-2062-4
Fax: 0-2530-2177
Website: http://www.mindterra.com
Email: info@mindterra.com

Login