banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Forum Index Thảo luận thâm nhập mọi người xem giùm lỗi SQL Injection của đoạn code này với ạ  XML
  [Question]   mọi người xem giùm lỗi SQL Injection của đoạn code này với ạ 15/05/2010 23:09:44 (+0700) | #1 | 210988
[Avatar]
docphongm41
Member

[Minus]    0    [Plus]
Joined: 02/03/2008 23:47:04
Messages: 10
Offline
[Profile] [PM]
Xin kính chào mọi người, mình đang làm bài luận về sql injection, sau khi tham khảo một số tài liệu, đọc đến đoạn tác giả minh hoạ một Procedure trong mysql dạng như sau:

Code:
delimiter /
create procedure sp_test (input varchar(30))
begin
set @param = input;
set @sql = concat('select count(*) from tbl_name where col_name like ''',@param,'%''');
prepare stmt from @sql;
execute stmt;
deallocate prepare stmt;
end
/


thông thường theo các khuyến cáo, xét về mặt viết code thì việc sử dụng prepared query có thể coi là tuơng đối an toàn. Mặc dù trong đoạn mã trên có thực hiện prepare truy vấn, nhưng đối số vẫn được nối trực tiếp vào truy vấn trước khi truy vấn được thực hiện prepare. Do đó rõ ràng (theo cách hiểu của mình) truy vấn đó không đạt được mục tiêu viết 1 lần, chạy nhiều lần (không cần tối ưu lại) của mô hình tham số hoá truy vấn.

Tác giả nói, đoạn code trên vẫn dễ bị tấn công. Mình đã thử nhiều cách để có minh hoạ chứng minh, nhưng vẫn chưa tìm được tham số nào có thể exploit cái lỗi mà tác giả nói.

Mong mọi người xem giùm và cho mình ý kiến với, xin chân thành cảm ơn. Thời gian gấp quá rồi smilie

ps: khi gọi call sp_test với lời gọi: call sp_test('a' or 1=1--') thì chắc chắn không exploit thành công nhé.
Perfection of sounds is the silence
[Up] [Print Copy]
  [Question]   mọi người xem giùm lỗi SQL Injection của đoạn code này với ạ 16/05/2010 22:32:22 (+0700) | #2 | 211046
[Avatar]
docphongm41
Member

[Minus]    0    [Plus]
Joined: 02/03/2008 23:47:04
Messages: 10
Offline
[Profile] [PM]
haizz, 51 view rồi mà không ai để lại cao kiến nào; Các anh em ơi, đây là một bài toán exploit rất thực tế mà.
Perfection of sounds is the silence
[Up] [Print Copy]
  [Question]   mọi người xem giùm lỗi SQL Injection của đoạn code này với ạ 17/05/2010 05:59:23 (+0700) | #3 | 211055
[Avatar]
conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
[Profile] [PM]

docphongm41 wrote:
Xin kính chào mọi người, mình đang làm bài luận về sql injection, sau khi tham khảo một số tài liệu, đọc đến đoạn tác giả minh hoạ một Procedure trong mysql dạng như sau:

Code:
delimiter /
create procedure sp_test (input varchar(30))
begin
set @param = input;
set @sql = concat('select count(*) from tbl_name where col_name like ''',@param,'%''');
prepare stmt from @sql;
execute stmt;
deallocate prepare stmt;
end
/


thông thường theo các khuyến cáo, xét về mặt viết code thì việc sử dụng prepared query có thể coi là tuơng đối an toàn. Mặc dù trong đoạn mã trên có thực hiện prepare truy vấn, nhưng đối số vẫn được nối trực tiếp vào truy vấn trước khi truy vấn được thực hiện prepare. Do đó rõ ràng (theo cách hiểu của mình) truy vấn đó không đạt được mục tiêu viết 1 lần, chạy nhiều lần (không cần tối ưu lại) của mô hình tham số hoá truy vấn.

Tác giả nói, đoạn code trên vẫn dễ bị tấn công. Mình đã thử nhiều cách để có minh hoạ chứng minh, nhưng vẫn chưa tìm được tham số nào có thể exploit cái lỗi mà tác giả nói.

Mong mọi người xem giùm và cho mình ý kiến với, xin chân thành cảm ơn. Thời gian gấp quá rồi smilie

ps: khi gọi call sp_test với lời gọi: call sp_test('a' or 1=1--') thì chắc chắn không exploit thành công nhé. 


---> Tác giả nói "dễ tấn công" nhưng tác giả có nói chính xác dễ tấn công trên CSDL nào? phiên bản nào không?

---> prepared statement nào cũng cần có input hết. Vấn đề quan trọng là tại sao kẻ tấn công có thể insert 1 cái gì đó để query trực tiếp? Ví dụ, tôi muốn lấy thông tin về 10 người gởi bài nhiều nhất trên diễn đàn, tôi chỉ cần cho application biết là tôi muốn như vậy là đủ. Việc thực thi query với một câu SQL thế nào hoàn toàn nằm sau "hậu trường" và chẳng có một cơ chế nào cho phép người tấn công có thể chèn SQL hết. Vấn đề nằm ở chỗ tôi không tạo điều kiện để chèn SQL chớ không phải ở chỗ tôi cho phép chèn SQL và tìm cách bảo mật làm sao sao để SQL được chèn vô không nguy hiểm.

---> Càng tạo sức ép "thời gian gấp quá" thì càng không có câu trả lời. Đây là tình trạng chung khi đưa ra một chủ đề và muốn người tham gia trả lời "gấp".
What bringing us together is stronger than what pulling us apart.
[Up] [Print Copy]
[digg] [delicious] [google] [yahoo] [technorati] [reddit] [stumbleupon]
Go to: 
 Users currently in here 
1 Anonymous

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|