Bài giảng Bảo mật ứng dụng Web (Web application security)

WEB APPLICATION SECURITY 
Author: Nguyễn Trường Phú – Nguyễn Tuấn Anh 
Date: 1-5-2015 
ABOUT AUTHOR 
•  Name: Nguyễn Tuấn Anh 
 Nguyễn Trường Phú 
•  Class: 23CCAN04 
•  Unit: An toàn ứng dụng 
CONTENT 
1.  Web application attack and defense 
2.  Modsecurity (mod_sec) 
Web Application 
attack and Defense 
Web Application Security 
Nền tảng Website phổ biến: 
•  Apache (httpd) 
•  Nginx 
•  IIS 
•  Apache Tomcat 
•  PHP 
•  ASPX (ASP.NET) 
•  JSP + Servlet (JAVA) 
•  HTML + CSS / HTML5 + CSS3 
•  Javascript / Jquery 
Client – Side 
Server - Side 
•  MySQL 
•  MariaDB 
•  MongoDB 
•  MemSQL 
•  Access 
•  SQLserver 
•  MSSQL 
•  .. 
+ + 
Web services: Databases: Languages: 
Web Application Security 
1 Website có thể bị tấn công như thế nào? 
•  Thông qua Authencation (Các hình thức tấn công vào mật khẩu, giao thức mã hoá, hình thức chứng thực,) 
•  Thông qua Session, Transport,. (Các hình thức tấn công qua bảo mật đường truyền bao gồm cả MITM) 
•  Thông qua Lổ hổng Web Application 
•  Thông qua Lổ hổng OS (Đặc biệt nhiều đối với Windows và khá ít đối với Linux) 
•  Thông qua Server Application/Software (Lổ hổng các service/software khác trên server: Mail, browser,adobe,java,) 
•  Thông qua Mã độc hoặc Backdoor được thiết lập từ trước 
•  Thông qua các hình thức tấn công từ chối dịch vụ (DoS, DDoS, DRDoS, Spam, ..) 
•  Thông qua Crawler hoặc các kẻ hở trong configure và quản lý (lổ hổng phân quyền, lộ tập tin, đường dẫn nhạy cảm,) 
•  Thông qua Tấn công vật lý 
•  Thông qua tâm lý con người (Social) 
Web Application Security 
Lổ hổng Web Application 
1.  Injection (SQLi, LDAPi, OS command injection,) 
2.  Cross Site Scripting (XSS) 
3.  Broken Authentication and Session Management (Nguy cơ về quản lý phiên/session) 
4.  Insecure Direct Object References (Các lổ hổng trong tham chiếu) 
5.  Cross Site Request Forgery (CSRF) 
6.  Security Misconfiguration (Lổ hổng trong cấu hình, triển khai dịch vụ web,) 
7.  Insecure Cryptographic Storage (Lổ hổng trong mã hoá dữ liệu nhạy cảm) 
8.  Failure to Restrict URL Access (Các lổ hổng quyền hạn truy cập url nhạy cảm) 
9.  Insufficient Transport Layer Protection (Lổ hổng đường truyền) 
10.  Unvalidated Redirects and Forwards (Các lổ hổng chuyển hướng) 
10 quy chuẩn bảo mật và cũng là 10 phân nhóm lỗ hổng bảo mật ứng dụng web theo OWASP 2010. 
Web Application Security 
Ví dụ về 1 số hình thức tấn công Web Application phổ biến: 
•  SQL injection (SQLi) 
•  Cross Site Scripting (XSS) 
•  Local File Inclusion (LFI) 
•  Remote File Inclusion (RFI) 
•  Local File Discluse/Download (LFD) 
•  .. 
Web Application Security 
 Định nghĩa: 
1. SQL injection 
SQL injection (SQLi) là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ 
hổng của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông 
báo lỗi của hệ quản trị cơ sở dữ liệu trả về để inject (tiêm vào) và thi hành các 
câu lệnh SQL bất hợp pháp 
Web Application Security 
Ví dụ: 
1. SQL injection 
Truy cập chuyên mục SQL trên ceh.vn thấy URL có dạng:  /index.php?page=SQl 
è  Câu truy vấn CSDL có dạng: “SELECT * FROM chuyenmuc WHERE tenchuyenmuc =“ + $page 
 Trong đó có thể $page=$_GET(‘tenpage’) 
Attacker cố tình truy vấn trên URL:  /index.php?page=SQl or 1=1 
è  Câu truy vấn CSDL có dạng: SELECT * FROM chuyenmuc WHERE tenchuyenmuc=SQl or 1=1 
Ta thấy vì 1=1 luôn đúng nên truy vấn trả lại tất cả những thông tin có trong bảng chuyenmuc 
⇒  Thông tin bị khai thác => Lỗi. 
Attacker có thể thực hiện truy vấn phức tạp hơn, truy vấn các cột, trường, thông tin quan trọng hơn. 
Web Application Security 
Định nghĩa: 
2. XSS 
XSS xuất hiện khi một ứng dụng web cho phép người dùng nhập các dữ liệu vào mà 
không thông qua kiểm duyệt nội dung, những dữ liệu này sẽ tương tác trực tiếp với 
những người dùng khác cùng sử dụng website. Nguy cơ tạo ra là hacker có thể 
chèn các mã kịch bản như HTML, Javascript (client side) nhằm ăn cắp 
SessionCookie, thay đổi giao diện (deface) hoặc chuyển hướng đến trang có mã 
độc khác. 
Web Application Security 
Định nghĩa: 
2. XSS 
Web Application Security 
Ví dụ: 
2. XSS 
if(!empty($_GET['name'])) 
{ 
 $name=$_GET['name']; 
 print $name; 
} else { 
Code lây $name trực tiếp từ giá trị khung name và in ra thẳng: 
Khi attacker không truy vấn bình thường mà inject mã javascript 
vào khung name ó Truyền 
giá trị trực tiếp cho biến name: 
alert(“Crazykid”) 
Lúc này được javascript được gán cho biến name và in ra 
Như một câu lệnh chứ không phải là 1 truy vấn bình thường 
ó đoạn javascript độc hại của attacker được thực thi 
Web Application Security 
Định nghĩa: 
3. LFI 
Lỗ hổng cho phép các attacker có thể truy vấn các tập tin nhạy cảm trên 
web server và đọc được 
Nội dung các tập tin đó. Ví dụ các tập tin nhạy cảm: /etc/passwd, /etc/
shadow, httpd.conf, 
Web Application Security 
Ví dụ: 
3. LFI 
Truy cập chuyên mục SQL trên ceh.vn thấy URL có dạng:  /index.php?page=SQl 
è  Nếu code trang view có dạng: 
<?php 
$Bien=$_GET[‘page’]; 
Include $Bien; ?> 
Attacker cố tình truy vấn trên URL:  /index.php?page=../../../etc/passwd 
è  Lúc này trở thành giống như là ta code như sau: 
<?php 
$Bien=$_GET[‘page’]; 
Include ../../../etc/passwd; ?> 
è  Attacker có thể đọc được nội dung của tập tin passwd trong đường dẫn ../../etc/ trên server 
ngay chính tại trang view. 
Chú ý ../ là chuyển lên một thư mục trong Linux. Nếu server windows thì dung ..\ ó URL lencode = %5C 
Web Application Security 
Định nghĩa: 
3. RFI 
Cho phép attack gọi đến một file trên web server hoặc trên server khác ngay tại web 
server này. 
Ví dụ: 
Nếu ceh.vn bị lỗi RFI thì nội dung trang vietnamnet.vn sẽ hiển hị trên ceh.vn 
Nếu attacker đặt backdoor trên vietnamnet.vn dạng: 
Tại ceh.vn attacker truy vấn:  
Thì nội dung backdoor shell.php sẽ được include vào source code của ceh.vn ó ta cắm 
backdoor trưc tiếp trên ceh.vn 
Web Application Security 
Ví dụ: 
3. RFI 
Code: 
<?php 
 $test=$_GET['test']; 
 include $test.'id=1'; 
 ?> 
Và register_globals = off 
Input: 
Out: 
Web Application Security 
Định nghĩa: 
3. LFD 
Giống LFI nhưng thay vì attacker có thể đọc các file nhạy cảm thì ở đây attacker có thể 
Download các file nhạy cảm về máy 
Web Application Security 
Ví dụ: 
3. LFD 
Đoạn code sau: 
 <?php 
 $test=$_GET['test']; 
 readfile($test); 
 ?> 
Hàm readfile() cho phép chúng ta đọc code file được truyền vào . 
Web Application Security 
Phát hiện, kiểm tra các lổ hổng Web Application: 
•  Ở vị trí attacker tấn công Opensource hoặc ở vị trị quản trị/chuyên gia an ninh kiểm thử Whitehat: 
 Đọc source code, Debug Source code tìm lổ hổng. 
•  Tấn công CloseSource, Đa số, kiểm thử Blackbox: 
q  Sử dụng phương pháp thủ công 
 Phương pháp Fuzzer vào các input 
(Nhập vào chuỗi ký tự ngẫu nhiên hoặc có mục địch nhằm xác định lổ hổng) 
Ví dụ: Thêm vào URL, khung Search, Login, các câu truy vấn, thay đổi method, tiêm vô số ký tự, 
q  Sử dụng phương pháp tự động 
Sử dụng các công cụ Scan, tìm kiếm lổ hổng 
Ví dụ: 
OpenSource: W3AF, Paros (Andiparos và Zed attack Proxy), Skipfish, Grabber, Zero Day Scan, 
CloseSource: Acunetix, N-stalker, NeXpose, Retina, AppScan, ParosPro, . 
Web Application Security 
Giải pháp Web Application Security: 
•  An Toàn Source code: Fix lổ hổng trong source code. Đưa ra 1 số hàm lọc, Security phù hợp 
•  Authencation: Áp dụng các hình thức mã hoá, chứng thực phù hợp (Kể cả mã hoá đường 
truyền (SSL, TLS,)) 
•  Đảm bảo toàn vẹn dữ liệu 
•  Permission: Phân quyền tập tin source code web, tập tin quan trọng server, quản trị web,
phù hợp 
•  Nâng cao kiến thức quản trị viên, tâm lý con người. 
•  Thủ thuật riêng (Tuỳ kinh nghiệm mỗi quản trị viên): Giả lập patch web home, Giấu Configure 
file, tạo bẫy (honeypot), thiết lập php.ini phù hợp, lợi dụng mod rewirte, .. 
•  Sử dụng Web Application Firewall 
Web Application Security 
Tại sao cần Web Application Firewall? 
Nếu 1 Server chứa hàng trăm website è Việc Fix code từng website sẽ gây tốn kém tiền bạc, thời gian, 
Vô tình bỏ sót lổ hổng hoặc tạo phản ứng ngược nếu đội ngũ Fix Code trình độ yếu, cần một lớp gia cố 
Chắn chắn bên ngoài 
è  Web Application Firewall: Nhanh, Tiết kiệm chi phí, công sức, hiệu quả lớn, 
nhiều tính năng mở rộng, Quản trị tập trung, . Và còn nhiều lợi ích khác 
Web Application Security 
Tại sao dùng Web Application khi có Firewall thông thường? 
Bởi vì ta cần những thứ firewall thông thường không có hoặc không được thiết kế với mục đích: 
Hoạt động và bảo vệ mạnh mẽ Layer 7, chống các cuộc tấn công layer 7. 
Phân tích, lọc, kiểm duyệt, thậm chí sửa đổi mạnh mẽ không chỉ header mà còn cả Request body, 
Request Response, được thiết kế để phù hợp với từng ứng dụng web, từng hệ thống web, 
Buffer các request/response để đảm bảo phân tích toàn diện vào bảo vệ tốt ứng dụng trong thời gian 
Thực 
Một số sản phẩm WAF cung cấp nhiều tính năng mở rộng như: Kiểm soát Cookies, Fake port, 
Fake Comment, Fake Compoment, . 
Web Application Security 
Sơ đồ triển khai hệ thống đề nghị (Chỉ đối với 1 hệ thống Web server) 
Web 
Server 
Database 
Server 
Reverse 
Proxy 
----- 
WAF 
(mod_sec) 
User 
Chú ý: WAF (Trong bài này là Mod_sec) và các luật chính của firewall tầng dưới sẽ triển khai tại Reverse 
Proxy. 1 Reverse Proxy có thể triển khai với nhiều Web Server. Tuỳ nhu cầu và điều kiện + Độ quan trọng 
Của DB mà triển khai Database riêng như mô hình hay để DB ngay tại Webserver còn Database triển 
Khai như một Server AD Backup hoặc gỡ bỏ để tiết kiệm chi phí. 
Web Application Security 
Một vài thắc mắc: 
Tại sao triển khai WAF trên Reverse Proxy? 
è  Để bảo toàn Web Server và các Server bên trong khi cuộc tấn công nặng nề. Attacker tiếp xúc trực 
Tiếp với reverse proxy. 
è  Giảm thiểu tài nguyên tiêu tốn cho Web server vì các WAF cần 1 lượng tài nguyên không nhỏ. 
è   WAF cũng có thể kiểm soát tài nguyên tĩnh được Caching trên Reverse Proxy (HTML, CSS,) 
Một số lời khuyên: 
Triển khai Reverse proxy với Nginx hoặc Apache (khuyên dùng Nginx vì độ chịu tải và caching) 
Có thể sử dụng Linux cho các server, Nếu sử dụng Linux cho các Server thì khuyên dùng firewall 
Application: modsecurity và Firewall tầng dưới dùng Iptables, lý do: Free, Mạnh mẽ, tuỳ biến mạnh, 
Modsecurity và Iptables có thể kết hợp với nhau hoàn hảo, Modsecurity có thể ra lệnh cho iptables 
Thực hiện các action khi cần thiết thông qua module hỗ trợ. 
Web Application Security 
ModSecurity 
Web Application Security Modsecurity 
Modsecurity (mod_Sec) là gì? 
•  Một Web Application Firewall (WAF) 
•  Được triển khai như là một Module của các web service 
•  Opensource, Có thể mở rộng và miễn phí 
 chỉ trả tiền nếu muốn có dịch vụ hỗ trợ 
Web Application Security Modsecurity 
Hoạt động ra sao? 
Kiểm soát chặt chẽ hoạt động của web server trên layer 7. Ghi log. Hành động theo luật 
Web 
Response 
Body 
Request 
Header 
Response 
Header 
Logging 
Request 
Body 
Web Application Security Modsecurity 
Hoạt động ra sao? 
Modsecurity có thể kiểm soát request và reponse trong cả header và body, nếu phát hiện các dấu 
Hiệu tấn công theo rules, Mod_sec sẽ thực hiện hoạt động đã được định sẵn theo từng Rules và ghi 
Logs lại các hành động đó 
Ví dụ: Phát triện trong Url truy vấn có ký tự () thì lập tức DROP. 
Ngoài ra Mod_sec còn có thể tạo hoặc chỉnh sửa các Request và Reponse. 
Web Application Security Modsecurity 
Triển khai Mod_sec 
(thực hiện triển khai trên Server Centos, Web service: apache) 
Yêu cầu: 
•  Apache 2.2x hoặc các phiên bản sau 
•  Libapr và Libapr-util 
•  Libpcre 
•  Liblua v1.5x hoặc các phiên bản sau này 
•  Module Mod_unique_id của apache phải được bật 
Web Application Security Modsecurity 
Triển khai Mod_sec 
(thực hiện triển khai trên Server Centos, Web service: apache) 
Cài đặt 
•  Download source Mod_sec tại trang chủ 
•  Tạm dừng Apache 
•  Biên dịch và cài đặt Mod_sec 
•  Load module mod_sec trong file cấu hình apache 
Lưu ý: trước khi biên dịch hãy cài trình biên dịch. Đối với Centos: yum groupinstall “Development Tools” 
Web Application Security Modsecurity 
Triển khai Mod_sec 
(thực hiện triển khai trên Server Centos, Web service: apache) 
Tạo tập tin config mod_sec ví dụ modsec.conf và include tập tin này trong file cấu hình apache 
Tạo tập tin chứa rules cho Mod_sec ví dụ rulesmod.conf 
Trong tập tin modsec.conf ta gõ: 
 SecRuleEngine On 
 SeDefaultAction 
“phase:1,deny,log,status:406,id:60008” 
 Include “/etc/httpd/conf.d/rulesmod.conf” 
Khởi động Apache. 
Sẽ giải thích rõ từng dòng khi Demo. 
Web Application Security Modsecurity 
Triển khai Mod_sec 
(thực hiện triển khai trên Server Centos, Web service: apache) 
Tạo tập tin config mod_sec ví dụ modsec.conf và include tập tin này trong file cấu hình apache 
Tạo tập tin chứa rules cho Mod_sec ví dụ rulesmod.conf 
Trong tập tin modsec.conf ta gõ: 
 SecRuleEngine On 
 SeDefaultAction 
“phase:1,deny,log,status:406,id:60008” 
 Include “/etc/httpd/conf.d/rulesmod.conf” 
Khởi động Apache. 
Sẽ giải thích rõ chức năng từng dòng khi Demo. 
Web Application Security Modsecurity 
Lỗi thường gặp khi cài mod_sec và giải pháp 
(thực hiện triển khai trên Server Centos, Web service: apache) 
mlogc.c:32:23: error: curl/curl.h: No such file or directory 
mlogc.c:2232: error: âCURL_GLOBAL_ALLâ undeclared (first 
use in this function) 
make[2]: *** [mlogc-mlogc.o] Error 1 
make[2]: Leaving directory `/usr/src/modsecurity-
apache_2.6.0/mlogc' 
make[1]: *** [all-recursive] Error 1 
make[1]: Leaving directory `/usr/src/modsecurity-
apache_2.6.0' 
make: *** [all] Error 2 
Giải pháp: Cài curl và curl-devel sử dụng lệnh: yum install curl* 
Sau khi cài xong, xoá Makefile và biên dịch lại. 
Web Application Security Modsecurity 
Cấu trúc Rules Mod_sec 
(thực hiện triển khai trên Server Centos, Web service: apache) 
SecRule VARIABLES OPERATOR [ACTIONS] 
VARIABLE: (WHERE?) Vị trí So sánh 
OPERATOR : (HOW?) Dấu hiệu căn cứ để so sánh 
[ACTIONS]: (WHAT?) Xử lý ra sao 
Trong đó: 
Web Application Security Modsecurity 
Ví dụ: 
(thực hiện triển khai trên Server Centos, Web service: apache) 
SecRule ARGS kid 
SecRule ARGS|REQUEST_HEADERS:User-Agent kid 
SecRule HTTP_Referer “www\.google\.com” 
SecRule ARGS "union\s+select" "deny,msg:'SQL Injection'" 
SecRule ARGS "union\s+all\s+select" "deny,msg:'SQL Injection'" 
SecRule ARGS "drop\s+table" "deny,msg:'SQL Injection'" 
SecRule ARGS "select\s+*" "deny,msg:'SQL " 
Web Application Security Modsecurity 
Các thành phân trong rule mod_sec: 
(thực hiện triển khai trên Server Centos, Web service: apache) 
VARIABLE: (WHERE?) Vị trí So sánh 
Web Application Security Modsecurity 
Các thành phân trong rule mod_sec: 
(thực hiện triển khai trên Server Centos, Web service: apache) 
OPERATOR : (HOW?) Dấu hiệu căn cứ để so sánh 
•  So sánh theo chuỗi thường 
•  So sánh theo toán tử 
Ví dụ so sánh toán tử: 
SecRule ARGS "!@rx ^CrazyKid$" 
Web Application Security Modsecurity 
Các thành phân trong rule mod_sec: 
(thực hiện triển khai trên Server Centos, Web service: apache) 
ModSecurity hỗ trợ 4 nhóm OPERATOR: 
• String–matching operators //so khớp string dùng toán tử 
• Numerical operators // So sánh số 
• Validation operators // Một vài toán tử đặc biệt so sánh các giá trị đặc biệt 
(XML, UTF-8,) 
• Miscellaneous operators // Các toán tử lọc. Dùng so sánh lộ thông tin CC, 
lộ thông tin người dùng,. 
Web Application Security Modsecurity 
Các thành phân trong rule mod_sec: 
(thực hiện triển khai trên Server Centos, Web service: apache) 
[ACTIONS]: (WHAT?) Xử lý ra sao 
ModSecurity chia các action thành 7 phân mục: 
• Disruptive actions 
• Flow actions 
• Metadata actions 
• Variable actions 
• Logging actions 
• Special actions 
• Miscellaneous Actions 
Web Application Security Modsecurity 
Các thành phân trong rule mod_sec: 
(thực hiện triển khai trên Server Centos, Web service: apache) 
Ví dụ Disruptive actions: 
-  Nếu xử lý khi so khớp thông tin = True thì thực hiện: 
+ Allow (cho phép) 
+Block (khoá) 
+Deny (chặn và gửi phản hồi) 
+pass (cho qua luật tiếp theo) 
+Drop (Loại bỏ và không phản hồi) 
+Pause (Tạm dừng) 
.. 
Web Application Security Modsecurity 
Câu hỏi đặt ra: 
Các quản trị viên không am hiểu Rules mod_sec có thể triển khai mod_sec một cách an toàn không? 
Giải pháp trong trường hợp này: 
CORE RULE SET (CRS) 
Hạn chế: Core rules set là tập hợp rules được viết cho đại đa số người dùng chứ không phải một 
Hệ thống cụ thể nào è Tính tuỳ biến, linh hoạt và bảo mật không đảm bảo bằng tự thiết kế rules 
Web Application Security Modsecurity 
Một số tính năng mở rộng khác của Modsecurity 
Fake port: 
Web Application Security Modsecurity 
Một số tính năng mở rộng khác của Modsecurity 
Fake robots.txt Disallow Entries 
Web Application Security Modsecurity 
Một số tính năng mở rộng khác của Modsecurity 
Fake hidden form fields 
Web Application Security Modsecurity 
Một số tính năng mở rộng khác của Modsecurity 
Làm chậm các công cụ scan lổ hổng tự động 
Web Application Security Modsecurity 
Modsecurity Logs 
Web Application Security Modsecurity 
Giải pháp Gui logs cho Modsecurity 
Một số giải pháp nguồn mở 
Cho việc monitor mod_sec 
Bằng giao diện đồ hoạ: 
Ví dụ: WAF-FLE 
Web Application Security Modsecurity 
Và còn rất nhiều tính năng khác 
Web Application Security Modsecurity 
Demo 
Q&A 
THANK YOU