Đề tài được thực hiện với mục đích tìm hiểu, phân tích các lỗ hổng bảo mật trong các ứng dụng web (cùng với chương trình minh họa) để qua đó đề xuất các phương án sửa chữa. Song song đó, luận văn còn thực hiện một chương trình “Tự động phát hiện lỗ hổng trên ứng dụng Web” giúp ích cho những nhà lập trình Web ít kinh nghiệm tránh những sai sót trong quá trình tạo các ứng dụng.
Trang 1NGHIÊN CỨU VÀ TRIỂN KHAI GIẢI
PHÁP BẢO MẬT CHO ỨNG DỤNG
WEB
Nơi thực tập: CTY TNHH Công Nghệ Thông Minh Smart Era.
Trang 3PHẦN 1:
LÝ THUYẾT
Trang 4OWASP Top 10 năm 2017 được phát hành
công khai, dựa trên cuộc thăm dò, kiểm tra
Trang 51 Tiêu chuẩn OWASP
1 Injection : ( SQL injection, OS injection, LDAP injection ) Các truy vấn đầu vào tại ứng dụng bị chèn
thêm dữ liệu không an toàn dẫn đến mã lệnh được gởi tới máy chủ cơ sở dữ liệu và biên dịch như một phần của mã lệnh
2 Broken Authentication and Session Management: (Session Fixation ) Do những đoạn chương
trình kiểm tra danh tính và quản lý phiên làm việc của người sử dụng thường hay được làm qua loa không đúng cách, tin tặc có thể dễ dàng xâm nhập, ăn cắp thông tin tài khoản, mật khẩu và khai thác các lỗ hổng khác bằng cách sử dụng các chứng chỉ đã đánh cắp
3 Sensitive Data Exposure: (Cleartext Storage of Sensitive Information, Cleartext Transmission of
Sensitive Information) Các dữ liệu nhạy cảm không được lưu trữ và bảo vệ cẩn thận, dẫn đến khi bị kẻ tấn công khai thác gây ra những ảnh hưởng to lớn cho hệ thống
4 XML External Entities: (Blind XXE Injection,Error based XXE Injection ) Khi DTD (Document Type
Definition <!DOCTYPE tên thẻ root [các thành phần trong thẻ root]>) được xử lý, ứng dụng có thể đọc hoặc nhúng file vào trong tài liệu XML Nếu có khả năng điều khiển được nội dung của DTD, khi đó kẻ tấn công có thể chỉ định truy xuất các tài nguyên nhạy cảm hoặc thực hiện các kiểu khai thác khác
5 Broken Access Control: Lỗ hỏng này liên quan đến những trường hợp nơi ứng dụng mắc lỗi bảo vệ
quyền truy cập vào dữ liệu và tính năng của nó, nghiêm trọng hơn là cho phép “kẻ phá hoại” thấy dữ liệu nhạy cảm của người dung khác được lưu trữ trên máy chủ
Trang 61 Tiêu chuẩn OWASP (tt)
6 Security Misconfiguration: (Error Codes,Insecure Configuration Management) Do việc cấu hình an
ninh lỏng lẻo tại các tầng trong kiến trúc web như nền tảng, OS, máy chủ ứng dụng, webserver, database,
… khiến cho kẻ tấn công có thể khai thác vào các ứng dụng, ví dụ để lộ ra những thông tin quan trọng khi trao đổi các gói tin
7 Cross-site Scripting: XSS cho phép tin tặc đưa các kịch bản phía máy khách vào các trang web công
cộng và trong nhiều trường hợp, tin tặc có thể sử dụng các công cụ kiểm soát truy cập của họ Chúng thực hiện bằng cách đánh lừa trình duyệt chấp nhận dữ liệu từ một nguồn không đáng tin cậy
8 Insecure Direct Object References (đối tượng tham chiếu thiếu an toàn): Lỗ hổng này xảy ra
khi chương trình cho phép người dùng truy cập tài nguyên (dữ liệu, file, thư mục, database) một cách bất hợp pháp, thông qua dữ liệu do người dùng cung cấp
9 Using Components With Known Vulnerabilities: Lổi này thường xảy ra khi sử dụng những phần
mềm, mã nguồn, hệ điều hành có những lỗ hổng bảo mật đã được public dẫn đến nhiều hậu quả nghiệm trọng
10 Improper Error Handling: Thường xảy trong quá trình xây dựng ứng dụng web thay vì chỉ hiển thị
thông báo lỗi, thì lại hiển thị ra những thông tin nhạy cảm như mã nguồn, cơ sỡ dữ liệu,
Trang 72 Một số phương thức tấn công ứng dụng
web
o Web Access Control: Thông thường hacker sẽ tấn công vào bằng
backdoor hoặc những mã độc nhầm chiếm quyền kiểm soát web
o Session Management: tấn công này nhầm chiếm hoặc lợi dụng phiên
làm việc của người dùng nhầm mục đích khai thác, tấn công vào hệ thống hoặc đánh cắp thông tin người dùng
o Input Validation: lợi dụng những ô nhập liệu để gửi đi một đoạn mã bất
kì khiến cho hệ thống phải thực thi đoạn lệnh đó
o Buffer Overflow: Một khối dữ liệu được gửi cho ứng dụng vượt quá bộ
nhớ được cấp phát khiến cho ứng dụng không thực thi được câu lệnh kế tiếp mà thay vào đó là thực thi đoạn lệnh do hacker đưa vào
o Directory indexing: Tấn công vào các thư mục đó thể chứa nội dung
quan trọng: tập tin cơ sở dữ liệu dự phòng, tập tin cấu hình, tập tin lưu trữ tạm thời, các kịch bản…
Trang 83 Một số giải pháp bảo mật
Các ứng dụng web thông thường dễ bị tấn công bằng cách dò quét, ddos Nhầm làm ảnh hưởng đến hoạt động bình thường của ứng dụng Những thiết bị an ninh tích hợp thông thường sẽ được sữ dụng nhầm chống những kiểu tấn công phá hoại này
Các thiết bị này thường có chức năng như 1 Firewall/IPS: có thể ngăn chặn, kiểm soát truy cập, phân tích hoặc loại bỏ dữ liệu độc hại trước khi đến server Ví dụ:
SandBlast, Arbor Spectrum, TRAPS
3.1 Bảo mật từ bên ngoài:
Trang 93 Một số giải pháp bảo mật (tt)
Web Application Firewall là một thiết bị phần cứng hoặc phần mềm được cài lên máy chủ có chức năng theo dõi các thông tin được truyền qua giao thức http/https
giữa trình duyệt của người dùng và máy chủ web tại lớp 7 Một WAF có khả năng
thực thi các chính sách bảo mật dựa trên các dấu hiệu tấn công, các giao thức tiêu chuẩn và các lưu lượng truy cập ứng dụng web bất thường Đây là điều mà các tường lửa mạng khác không làm được
Mô hình WAF
Trang 103 Một số giải pháp bảo mật (tt)
▪ ModSecurity: Đây là phần mềm nguồn mở có thể hoạt động như một
module trong máy chủ Apache hoặc là một thành phần độc lập
ModSecurity sử dụng biểu thức chính quy trong việc bảo vệ máy chủ web
từ các cuộc tấn công được xác định trước dựa theo các dấu hiệu hoặc các cuộc tấn công bất thường khác Bên cạnh đó, ModSecurity cũng có khả năng lọc các siêu ký tự do người dùng chèn vào ứng dụng web
▪ URLScan: Đây là một sản phẩm của Microsoft dành riêng cho các máy
chủ web IIS URL scan không chỉ bảo vệ máy chủ IIS khỏi các điểm yếu
từ các phiên bản cũ hơn mà còn cung cấp thêm các biện pháp bảo vệ
khác như lọc dữ liệu mã hóa trên URL hoặc lọc các siêu ký tự do người
dùng chèn vào để chống lại các loại tấn công như XSS, SQL Injection,…
▪ WebKnight: Đây cũng là 1 sản phẩm dành cho các máy chủ web IIS.
Trang 113 Một số giải pháp bảo mật (tt)
▪ Giao thức HTTPS ( Hypertext Transfer Protocol Secure) là sự kết
hợp giữa giao thức HTTP và giao thức bảo mật SSL, TLS nhằm tạo nên
một rào chắn an ninh, bảo mật khi truyền tải các thông tin trên mạng
Internet.
Trang 123 Một số giải pháp bảo mật (tt)
Trong việc lập trình cần lưu ý kiểm tra và chuẩn hóa các giá trị đầu vào, đầu ra Kiểm soát các thao tác với file, mã hóa dữ liệu nhạy
cảm, kiểm tra kĩ các dữ liệu và quyền được cấp cho người dùng
Việc sữ dụng những công nghệ mới cũng rất quan trọng và cần thiết
3.2 Bảo mật trong lập trình
3.2.1 Sơ lược:
3.2.1 Bảo mật với Cross-Origin Resource Sharing:
- Là một kỹ thuật được sinh ra để làm cho việc tương tác giữa client và server được
dễ dàng hơn, cho phép JavaScript ở một trang web có thể gửi yêu cầu lên một REST
API được host ở một tên miền khác
- CORS sử dụng một số HTTP headers trong cả request và response để cho phép
việc truy xuất tài nguyên không cùng một origin có thể xảy ra, mà vẫn đảm bảo độ bảo
mật.Về cơ bản thì từ phía server sẽ thông báo cho trình duyệt biết là server chỉ chấp
nhận resquest từ origin nào và những phương thức HTTP nào
Trang 133 Một số giải pháp bảo mật (tt)
3.2.1 Kỹ thuật Cross-Origin Resource Sharing (tt) :
Cơ chế hoạt động của CORS:
- Phía client sẽ tạo request một trong những
phương thức GET, POST, PUT, HEAD để yêu
cầu server làm một việc gì đó Những request
này sẽ được đính kèm một header tên là Origin
để chỉ định origin của client (domain)
- Server sẽ xem xét Origin nếu hợp lệ, server
sẽ trả về response kèm với header
Access-Control-Allow-Origin Header này sẽ cho biết
xem client có phải là nguồn hợp lệ để
browser tiếp tục thực hiện quá trình request
=>> Kĩ thuật này có thể giúp hạn chế XSRF
Trang 14hiện ánh xạ cơ sỡ dữ liệu sang các
đối tượng trong các ngôn ngữ lập
trình hướng đối tượng như Java,
C# …(các table tương ứng các
class, mối ràng buộc giữa các
table tương ứng quan hệ giữa các
class ‘has a’ , ‘is a’)
3.2.2 Kỹ thuật Object Relational Mapping
Object Relational Mapping
=>> Kĩ thuật này giúp hạn chế SQL INJECTION
Trang 153 Một số giải pháp bảo mật (tt)
3.2.3 JSON web token (JWT)
JWT là cơ chế bảo mật đối với các API RESTful, các thông tin trong chuỗi JWT được định dạng bằng JSON Trong đó chuỗi Token phải có 3 phần là header , phần payload và phần signature được ngăn bằng dấu “.”
JSON WEB TOKEN
Trang 173 Một số giải pháp bảo mật (tt)
3.2.4 Một số Framework khác tích hợp sẳn khả năng bảo mật cho ứng dụng web
Entity Framework và LINQ
o Entity Framework (EF) là một framework ánh xạ quan hệ đối tượng (ORM) dành
cho NET
o LINQ (Language Integrated Query) Khi muốn truy vấn, làm việc với CSDL ta chỉ việc gọi
và truy xuất các hàm, thủ tục tương ứng của LINQ mà không cần quan tâm đến các câu
lệnh SQL thông thường Các toán tử truy vấn chuẩn cung cấp các khả năng truy vấn bao gồm lọc, tham chiếu, kết hợp, sắp xếp và nhiều chức năng khác giúp phòng chống rất
hiệu quả những lỗ hỏng như SQL Injection, XSS
Angular, React và Vue: là những Framework có khả năng chuẩn hóa dữ liệu đầu ra rất mạnh
mẽ với DomSanitizer những dữ liệu khi được thể hiện dưới dạng html sẽ được lọc và đối với những dữ liệu nguy hiểm những tính năng này của sẽ giúp phòng chống XSS rất mạnh mẽ
Django, CodeIgniter , Spring Security, Laravel : đây cũng là framework mã nguồn mở
được tích hợp sẳn những tính năng phòng chống rất tốt những lỗ hỏng thông thường trong top
10 OWASP
Trang 18PHẦN 2:
THỰC
HÀNH
18
Trang 191 Sơ lược ứng dụng Customer Email
Ứng dụng sữ dụng hai framework mới bao gồm: ASP.NET Core 2.0 và Angular 5 được ra đời vào giai đoạn cuối năm 2017
Xây dựng thành: Web API : phía server trả về dữ liệu dạng json (back-end ASP.NET Core 2.0) và phía client nhận và hiển thị dữ liệu với Angular 5.
ANGULAR
ASP.NET CORE API
DATABASE
USER
Client Application: Desktop app ( Win, Mac, Linux ) / Browser / Mobile app (Android IOS)
Web API (server application) / IIS
MSSQL ServerAcess
Trang 202 Broken Acess Control
2.1 Nguy cơ lỗ hỗng
Đây là một vấn đề nghiêm trọng đối với web API vì server và client nằm ở 2 vị trí khác nhau
Nếu không có một cơ chế xác thực nào hacker dễ dàng lấy toàn bộ dữ liệu nếu biết cách gọi
API
http://localhost:52045/api/get/duong
HACKER
Trang 212 Broken Acess Control (tt)
2.2 Hạn chế lỗ lỗng
Để hạn chế lỗ hổng này điều quan trọng nhất là phải kiểm tra được người dùng đó là ai, có
thể thao tác những gì trong hệ thống, ngăn chặn việc leo thang quyền hoặc đánh cắp dữ liệu
của người khác
Trang 222 Broken Acess Control (tt)
2.2 Hạn chế lỗ lỗng (tt)
Nhưng sau khi có token, user vẫn có thể xem mail của user khác Thay vì gửi yêu cầu đến
/api/getmail/duong1234 thay đổi thành /api/getmail/duong như vậy toàn bộ dữ liệu của user
duong sẽ được thể hiện
Trang 232 Broken Acess Control (tt)
2.2 Hạn chế lỗ lỗng (tt)
Như vậy để phòng chống lổ hỗng này cần phải kiểm tra lại user được đính kèm trong đoạn
token được mã hóa và thông tin của user này có hợp lệ hay không sau đó mới trả về dữ liệu
Trang 242 Broken Acess Control (tt)
2.3 Kiểm thử lỗ hỗng
Tiến hành thử nghiệm với việc lấy dữ liệu nhưng không có đoạn token hợp lệ Ứng dụng sẽ trả
về lỗi 401 thông báo rằng user không có quyền với thao tác này vì trong request không chứa
đoạn Authorization: Bearer với token hợp lệ được cấp từ server
Trang 252 Broken Acess Control (tt)
2.3 Kiểm thử lỗ hỗng (tt)
Ở một mức độ phức tạp hơn chúng ta tiến hành tấn công bằng cách thay đổi yêu cầu đến
server để lấy thông tin từ một user khác http://localhost:52045/api/getmail/duong
Trang 262 Broken Acess Control (tt)
2.3 Kiểm thử lỗ hỗng (tt)
Ở một mức độ phức tạp hơn chúng ta tiến hành tấn công bằng cách thay đổi yêu cầu đến
server để lấy thông tin từ một user khác http://localhost:52045/api/getmail/duong
Trang 283 Cross site scripting (tt)
3.3 Phòng chống lỗ hỗng
Nhưng vấn đề chủ yếu ở đây là vẫn cho phép hiển thị dữ liệu HTML bên cạnh đó vẫn
tiến hành ngăn chặn những thẻ độc bằng cách dùng một “Pipe” được cung cấp bởi
Angular và Angular sẽ giúp chúng ta ngăn chặn những giá trị độc hại không cho chúng
thực thi nhưng đối với những đoạn mã lệnh an toàn vẫn sẽ hiển thị, trong ứng dụng này
chúng ta sẽ dùng Pipe có tên là sanitizeHtml:
Trang 293 Cross site scripting (tt)
3.4 Kiểm thử lỗ hỗng
Trang 314 SQL INJECTION (tt)
4.2 Hạn chế lỗ hỗng
Sữ dụng LINQ và EntityFramwork
Phương thức: IEnumerable<T> hay IQueryable<T> và các toán tử truy vấn dữ liệu như
Where, Any, Giúp lọc các giá trị không hợp lệ từ request Bên cạnh đó cả ứng dụng phía client và server đều lọc, xác nhận lại với biểu thức chính quy (REX) nhầm nâng cao tính
bảo mật dù việc này không thật sự cần thiết nhưng sẽ gây khó khăn cho hacker
"duong\" || \"1\"=\"1“ trước dấu “ chèn \ Query k hợp hệ, ko nhận, k phản hồi
Trang 324 SQL INJECTION (tt)
4.1 Kiểm thử lỗ hỗng
Biểu thức được mã hóa base64 dạng username:password Chúng
ta sẽ thử tấn công Authorziation Basic với đoạn mã là admin:1’ or
1=1# và encode base64: YWRtaW46MScgb3IgMT0xIw==
Tương tự với hàng loạt câu lệnh khác:
1” or “1” = “1”
1%22%20or%20%221%22%3D%221%22
/*union*/union/*select*/select+1,2,3/*
Trang 345 Cross-site request forgery
5.1 Nguy cơ lỗ hỗng
Lỗ hỗng này thường xảy ra khi attacker cố tình lừa người dùng nhầm thực hiện một thao
tác nào đó Như hình bên dưới người dùng khi truy cập vào sẽ tự động xóa id 2019
Trang 355 Cross-site request forgery
5.2 Phòng chống lỗ hỗng
• Lưu trữ dữ liệu cục bộ - HTML5 Local Storage : thông thường lỗ hỗng dựa trên
cookie (gửi theo mỗi request) người dùng, để hạn chế lỗ hỗng có thể lưu token ở
Local Storage
• Sữ dụng kỹ thuật CORS nhầm chặn những request từ domain không được cấp phép
• Sữ dụng XSRF-TOKEN hoặc Captcha ( theo OWASP) nhầm ở mỗi thao tác quan
trọng khi bị lừa hacker sẽ không thể nào giả mạo đoạn mã được tạo ngẫu nhiên
Trang 365 Cross-site request forgery
5.3 Kiểm thử lỗ hỗng
• Kiểm tra hoạt động của chính sách CORS Chúng ta sẽ cho chính client chạy trên
port 4201 thay vì 4200 ( đã được cấp phép)
Kết quả chúng ta không thể gửi Preflight request (OPTION) do địa chỉ không phù hợp chính sách đã
thiết lập nên các yêu cầu sau đó không được thực hiện.
Trang 375 Cross-site request forgery
5.3 Kiểm thử lỗ hỗng
Tuy nhiên tin tặc vẫn có thể có một phương thức nào đó để giả mạo phần http header
bằng nhiều phương thức mà tấn công đến server
Cố gắng bỏ qua hoặc tạo re reCAPTCHA
ảo đều không có hiệu quả do người dùng phải trực tiếp thao tác thì mới tạo được captcha hợp lệ