oracle of Oracle

รูปจาก Iron man2
...

Security-driven design #2 - SQL Injection

ผมเขียนตอนแรก ไว้ที่ เป็นเรื่องเกี่ยวกับการโจมตีจุดอ่อน XSS
บทความในตอนนี้เป็นตอนต่อเนื่องที่พูดเกี่ยวกับจุดอ่อนที่เรามักพบกันได้บ่อย นั่นคือ SQL Injection โดยเป็นการโจมตีโดยการฉีค SQL query ผ่านช่องทางต่างๆ ที่ให้เราส่ง input จาก client ไปหาตัวระบบได้ เมื่อทำสำเร็จแล้วผู้โจมตีจะสามารถเข้าถึงข้อมูลเพื่อทำ CRUD ที่อยู่ในฐานข้อมูลได้ โดยไม่ต้องผ่านการตรวจสอบสิทธิของ application นั้นๆ
ผลกระทบของ SQL Injection ขึ้นอยู่กับปัจจัยเหล่านี้

• จุดที่ฉีคเข้ามา query
• สิทธิของ user ที่ execute query นั้น
• database platform และ version
• database configuration

ยกตัวอย่าง SQL Injection ที่เกิดขึ้นเมื่อนักพัฒนาสร้าง dynamic query โดยนำมารวมกับ input ที่ผู้ใข้ส่งเข้ามาโดยไม่ผ่านวิธีการที่เหมาะสม

String query = “Select * from Users Where username = ‘“ + request.getParameter(”username”) + “‘ and password = ‘“ + request.getParameter(”password”) + “‘“;
  try {
    Statement statement = connection.createStatement( … );
    ResultSet results = statement.executeQuery( query );
  }

แล้วถ้าใช้ url ลักษณะนี้
http://www.yoursite.com/login?username=tofu’%20or%20‘1’%20=%20’1&password=1’%20or%20’1’%20=%20’1
เท่ากับเราจะได้ query ที่ค่าจะออกมาเป็น true และ query ผลลัพธ์ออกมาได้

Select * from Users Where username = ‘tofu’ or ‘1’=’1’ and password=’1’ or ‘1’=’1’ 

นอกจากนี้ยังมี query อีกสารพัดแบบที่ถูกฉีคเข้ามาทดสอบความอ่อนแอของ application เราหาได้ใน google

แนวทางป้องกันหลัก

• Parameterized query
• ใช้ Prepared Statement / HQL / ...
• ใช้ Stored Procedures
• Character escaping
• User-input Handling ได้กล่าวไปในบท ก่อนหน้านี้ และดูเพิ่มเติมได้จาก นี้
• ซ่อน error message ที่มาจาก database server เนื่องจากการทำ SQL injection จะเกิด error message ที่ return ออกมาจาก
• database server ได้ซึ่ง message ดังกล่าวมันช่วยให้ผู้ไม่ประสงค์ดีนำไปวิเคราะห์ และนำกลับมาโจมตีเราใหม่
• ใช้ user ที่มีสิทธิ์เท่าที่จำเป็นต่อการ execute query นั้นเท่านั้น ไม่ควรใช้ sa, dba หรือ admin

ตัวอย่างการใช้ Prepared Statement เพื่อส่งผ่าน parameter

String query = “Select * from Users Where username = ? and password = ?”;
  try {
    PrepareStatement pstmt = conn.prepareStatement(query);
    pstmt.setString(1, username);
    pstmt.setString(2, password);
    ResultSet results = pstmt.executeQuery(query);
  }

ใน query language ของ framework ต่างๆ ก็มี parameter statment ให้ใช้ เช่น Hibernate Query Language (HQL)

Query query = session.createQuery(”from Users where username =:username and password =:password”;
  query.setParameter(”username”, username);
  query.setParameter(”password”, password);

ตัวอย่างการใช้ Stored Procedure เพื่อส่งผ่าน parameterized query

String username = request.getParameter(”username”);
  String password = request.getParameter(”password”);
  try {
   CallableStatement cs = conn.prepareCall(”{call getUsers(?, ?)}”);
   cs.setString(1, username);
   cs.setString(2, password);
   ResultSet results = cs.executeQuery();
  } 

เทคนิค Escape อีกทางเลือกหนึ่งกรณีที่เราไม่ใช้ Parameterized query และส่งผลต่อ ประสิทธิภาพ ถ้าใช้งานอย่างไม่เหมาะสม เพื่อสร้าง dynamic query ลองเลือกเทคนิค Escape (เช่นเดียวกับ Java ที่มี character escaping) แต่อย่างไรก็ตามเทคนิคนี้ค่อนข้างเปราะบางกว่าเมื่อเทียบกับ parameterized query อ่านรายละเอียด character escaping ของ DBMS แต่ละเจ้าได้ดังนี้

• Oracle
• MySql
• SQL Server

ศึกษาตัวอย่าง escape ได้จากโค้ด OracleCodec class ของ owasp-esapi

//encode ' to '' 
  public String encodeCharacter( char[] immune, Character c ) { 
    if ( c.charValue() == '\'' ) 
      return "\'\'";
    return ""+c; 
  } 

Note: การเลือกใช้ PreparedStatement หรือ Statement และการเพิ่มประสิทธิภาพการทำงาน เพิ่มเติม: Review Code for SQL Injection Test for SQL Injection Reference: SQL injection

Improve performance in JDBC

เลือก Driver ให้เหมาะกับงานที่กำลังทำอยู่
JDBC สร้าง driver ออกมาสี่ประเภทขึ้นอยู่กับความต้องการที่เราจะต้องเลือกไปใช้

• JDBC-ODBC ใช้เมื่อไม่มี driver ที่สร้างสำหรับภาษา Java แต่มีรองรับ ODBC แต่การเชื่อมต่อด้วยแบบนี้จะช้ากว่าประเภทอื่นๆ เพราะต้องเรียกผ่าน ODBC อีกทีหนึ่ง
• Native API ใช้เมื่อมี driver ที่สร้างสำหรับ Java เพื่อไม่ต้องผ่าน ODBC เหมือนกับแบบ JDBC-ODBC ดังนั้นประสิทธิภาพจึงดีกว่าประเภทที่ 1 แต่ประสิทธิภาพจะปานกลาง เมื่อเทียบกับแบบที่ JDBC-Net
• JDBC - Net ใช้เมื่อติดต่อผ่าน proxy server เช่นพวก application server ทั้งหลาย (websphere, weblogic, ...) ประเภทนี้ง่ายต่อการ optimization เช่น connection pooling, caching, loga balancing และอื่นๆ

เลือกที่จะควบคุม transaction เอง
java.sql.Connection interface เตรียม method เพื่อจัดการกับ transaction ดังนี้

• boolean getAutoCommit();
• void setAutoCommit(boolean autocommit);
• void commit();
• void rollback();

ด้วย default JDBC transaction จะ commit ให้เองเมื่อแต่ละ statement ถูก execute นั่นคือ AutoCommit mode เป็น true โดยเราไม่จำเป็นต้องเรียก commit() method เอง มันง่ายต่อนักพัฒนา ถ้าเราต้องการ execute แค่หนึ่ง statement แต่จะให้ประสิทธิภาพที่ไม่ค่อยดีเมื่อมีหลาย statement ที่ต้อง execute เพราะว่ามันจะ commit หลังจากที่ statement แรกทำงานจบโดย default จึงควรตั้ง AutoCommit mode เป็น false และเรียก commit() method หลังจากเรียกกลุ่มของ statement execute เอง และใช้ rollback() method ใน catch block เมื่อไหร่ก็ตามที่เกิด exception ขึ้นในโปรแกรม

ตัวอย่าง 

try{
    connection.setAutoCommit(false);
    PreparedStatement ps = connection.preareStatement( "UPDATE employee SET Address=? WHERE name=?");
    ps.setString(1,"Austin");
    ps.setString(2,"RR");
    ps.executeUpdate();
    PreparedStatement ps1 = connection.prepareStatement( "UPDATE account SET salary=? WHERE name=?");
    ps1.setDouble(1, 5000.00);
    ps1.setString(2,"RR");
    ps1.executeUpdate();
    connection.commit();
    connection.setAutoCommit(true);
    }catch(SQLException e){ connection.rollback();}
    finally{
             if(ps != null){ ps.close();}
             if(ps1 != null){ps1.close();}
   if(connection != null){connection.close();}
}

Statement vs PreparedStatement
เรามักเข้าใจผิดว่า PreparedStatement จะให้ประสิทธิภาพที่ดีกว่าเมื่อหยิบมาใช้งาน ความจริงแล้วใช่ว่าจะเป็นเช่นนั้น เมื่อเราใช้ PreparedStatement object เพื่อ execute SQL Statement มันจะถูก compile และเก็บไว้ใน cache และเมื่อเราเรียกใช้อีกมันจะไม่ถูก compile เป็นครั้งที่สอง เพราะมันจะถูกพบใน cache และนำกลับมาใช้ใหม่ ซึ่งเป็นการเพิ่มประสิทธิภาพการทำงานเพราะลดเวลา compileแต่เมื่อเราใช้ Statement ทุกครั้งที่เราจะ execute SQL Statement มันจะถูก compile ใหม่ทุกครั้งถ้าดูตามเหตุผลด้านบนนี้ PreparedStatement เหมาะสมกับการถูกนำมาใช้อย่างยิ่ง แต่ ความจริง ไม่ได้เป็นอย่างนั้น
เมื่อเราเห็นผลการทดสอบดังกล่าว จะสรุปได้ว่าสำหรับ enterprise application ที่มีผู้ใช้จำนวนมากที่จะ execute SQL statement เดียวกันบ่อยๆ การลดเวลา compile ได้สามารถช่วยเพิ่ม performance ให้กับ database ได้ แต่สำหรับ client-side การใช้ PreparedStatement ใช้เวลานานกว่า Statement
แต่ถึงอย่างไรถ้าเรากังวลกับเรื่องของ SQL injection PreparedStatement ก็จะเป็นตัวเลือกที่สมควรหยิบไปใช้

นอกจากนี้ยังมีอีกหลายประเด็นทีน่าสนใจเช่นเรื่องของ batch, pre-fetch value ที่ผมยังไม่มีเวลาสรุป ลองศึกษาเพิ่มเติมได้ครับ

Referenece:
http://oreilly.com/catalog/jorajdbc/chapter/ch19.html