Cách phòng tránh OWASP Top 10 Security Risk

25th Jan 2021
Table of contents

Theo quan điểm cá nhân: xuất phát điểm của một phần mềm thiếu an toàn đến từ việc thiếu hoặc bỏ qua phần security trong tài liệu mô tả phần mềm, kế đó là sự bất cẩn của engineer và việc bỏ qua bước security testing trước khi sản phẩm được đưa lên production.

>> OWASP - 10 lỗ hổng bảo mật Web ứng dụng phổ biến

>> OWASP và Quy trình pentest chia thành 11 công việc

Và cũng theo quan điểm cá nhân: một cách để để giảm rủi ro về lỗi bảo mật cho sản phẩm thay vì đa số sẽ bị động xử lý lỗi bảo mật thì chúng ta nên chủ động trong việc phòng tránh, việc thường xuyên chia sẽ về bảo mật cho các thành viên từ manager, engineer và QA sẽ giúp nhắc nhớ vấn đề này khi làm việc.

OWASP Top 10 Web Application Security Risks

Nói đến những tổ chức về security không ai không nhắc đến OWASP (Open Web Application Security Project) , đây là một tổ chức phi lợi nhuận, những thành viên trong tổ chức là những tình nguyện viên và họ toàn là những tay cợm cán về security đến từ nhiều nơi trên thế giới, họ chia sẽ những kinh nghiệm về sản phẩm của mình và cùng tay tạo nên OWASP.

Sự dịch chuyển của công nghệ thông tin cũng sẽ ảnh hưởng đến danh sách Top 10 này hằng năm, với năm 2017 sẽ là:

  • A1: Injection
  • A2: Broken Authentication
  • A3: Sensitive Data Exposure
  • A4: XML External Entities
  • A5: Broken Access Control
  • A6: Security Misconfiguration
  • A7: Cross-Site-Scripting(XSS)
  • A8: Insecure Deserialization
  • A9: Using Components with Know Vulnerabilities
  • A10: Insufficient Logging & Monitoring

A1: Injection

SQL, NoSQL, OS, Command Injection and LDAP injection là những loại phổ biến của những lỗi về Injection, nó xảy ra khi những dữ liệu không tin cậy được gửi về server và thực thi những query hay command từ đó truy cập vào dữ liệu của ứng dụng hoặc thực thi những câu lệnh không mong muốn.

Những ứng dụng có thể dễ bị tấn công khi:

  • Dữ liệu của người dùng không được validate, filter một cách đúng đắn.
  • Ứng dụng có Dynamic queries.

Ví dụ SQL Injection:

Một ứng dụng sử dụng trực tiếp dữ liệu của người dùng cho việc thực thi câu query:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Sau đó Attacker điều chỉnh parameter id trên browser

http://example.com/app/accountView?id=' or '1'='1

Ví dụ Command Injection

Attacker muốn đưa operating system command xuống web server và web server sẽ thực thi nó. Ví dụ một tính năng của web dùng để đọc file, với file name được lấy động từ URL.

http://sensitive/cgi-bin/userData.pl?doc=user1.txt

Sau đó Attacker điều chỉnh parameter id trên browser

http://sensitive/cgi-bin/userData.pl?doc=/bin/ls

| or

http://sensitive/cgi-bin/userData.pl?doc=user1.txt%3Bcat%20/etc/passwd

Cách phòng tránh

  • Nên sử dụng Object Relational Mapping Tools(ORMs) trong việc tương tác Database.
  • Có thể tích hợp những tool để scan code trong CI/CD như static source (SAST) hay dynamic application test (DAST).
  • Hoặc sử dụng API để tương tác đến Database
  • Validate dữ liệu người dùng, escape special characters
  • Sử dụng LIMIT để tránh bị mất toàn bộ data trong trường hợp bị Injection.
  • Đối với Command Injection, cần review kỹ những chỗ có thực thi lệnh command bởi các keywords: system (shell_exec, exec, proc_open, eval, passthru, proc_open, expect_open, ssh2_exec, popen)
  • Cần kiểm tra kỹ Permission của web application, kể cả Database user, kể cả operating system command execution.

A2: Broken Authentication

Những tính năng liên quan như đăng nhập, session management nếu không implement một cách chính xác sẽ dễ cho Attacker vượt qua bước đăng nhập hoặc chiếm quyền sử dụng của user. Một cách mà các Attacker thường sử dụng là dùng tools để thử đăng nhập với hằng triệu tập username và brute force password.

Những điểm yếu như:

  • Ứng dụng cho phép một công cụ tự động gửi nhiều request để đăng nhập, sau đó Attacker sẽ dùng tool để quét cạn username và password để tìm ra cặp user/pass có trong ứng dụng.
  • Ứng dụng cho phép sử dụng những password yếu hoặc vô ý chưa remove những user/pass mặc định.
  • Tính năng quên mật khẩu nhưng thiếu an toàn với những câu hỏi dạng kiến thức.
  • Ứng dụng sử dụng plain text hoặc mã hoá đơn giản để lưu password.
  • Phơi bày session id trong URL.
  • Không regenerate session id sau khi login thành công.

Cách phòng tránh

  • Nếu có thể nên implement two-factor authentication.
  • Sử dụng captcha hay chặn client gửi nhiều request nhằm dò tìm user/pass bằng cách brute force.
  • Implement weak-password checks, tăng chiều dài của password hoặc có thể xem xét không sử dụng top 1000 password phổ biến
  • Change default password của các service.
  • Giới hạn và tăng thời gian chờ vài lần cố gắng đăng nhập.

A3: Sensitive Data Exposure

Những ứng dụng web hay API không bảo vệ những dữ liệu nhạy cảm một cách đúng đắn và để rò rỉ những thông tin như tài chính, sức khoẻ của khách hàng, thông tin cá nhân, credit card...Hoặc đôi khi việc chia sẽ những tài liệu cá nhân cho bên thứ 3 sẽ thuộc loại quy phạm quy định pháp luật tuỳ vào quy định của từng quốc gia.

Cần bảo vệ như thế nào?

  • Kiểm tra việc lưu trữ sensitive data như thế nào, có phải plain text không? Dữ liệu backup như thế nào?
  • Không lưu trữ sensitive data nếu không cần thiết.
  • Đảm bảo mã hoá tất cả các sensitive data.
  • Sử dụng những phương thức bảo mật trong khi truyền/nhận data, TLS, HTTPS.
  • Kiểm tra việc chia sẽ sensitive data cho bên thứ 3.

A4: XML External Entities (XXE)

Những cấu hình dạng XML để lộ những thông tin như URI handler, internal file shares, port rất dễ bị Attacker lợi dụng để tấn công

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
Scenario #2: An attacker probes the server's private network by
changing the above ENTITY line to:
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
Scenario #3: An attacker attempts a denial-of-service attack by
including a potentially endless file:
<!ENTITY xxe SYSTEM "file:///dev/random" >]>

A5: Broken Access Control

Việc hạn chế cái mà user đã đăng nhập mới được xem hoặc được làm trong ứng dụng nếu implement không chính xác sẽ bị Attacker lợi dụng mà không cần tới việc đăng nhập.

Cách phòng tránh

  • Ngoại trừ những public resource, việc phân quyền nên set Deny sẽ là default.
  • JWT nên inactive sau khi user logout.

A6: Security Misconfiguration

Attackers thường khai thác những lổ hổng chưa được vá hoặc truy cập tài khoản mặc định của các service sử dụng trong ứng dụng kể cả ở tầng network, web-server, platform, database, containers,...

Cách phòng tránh

  • Nên xem xét dọn rác những tính năng, service không cần thiết.
  • Kiểm tra và dọn dẹp những user mặc định.
  • Theo dõi các bảng cập nhật của từng service.

A7: Cross Site Scripting (XSS)

XSS là lỗi xảy ra nhiều thứ 2 trong Top 10 OWASP, ứng dụng bị lỗi XSS có thể ở dạng bị vỡ cấu trúc DOM của website hay load và thực thi một javascript nguy hại, từ đó Attacker có thể chơm thông tin cá nhân, thông tin đăng nhập, session,...

Cách phòng tránh

  • Cẩn thận với những tính năng mà cho phép website hiển thị những dữ liệu mà chưa được validate hay escape từ người dùng.
  • Ứng dụng lưu trữ những data chưa được validate từ user sau đó hiển thị cho những user khác. Cần escaping những data không an toàn từ người dùng.

A8: Insecure Deserialization

Việc deserialization không an toàn rất dễ dẫn đến sẽ execute một script từ attacker. Ví dụ như bạn lưu một deserialization ở cookie hay localstorage và dùng data đó cho việc kiểm tra phân quyền.

A9: Using Components with Know Vulnerabilities

Việc dùng những components, libraries, frameworks không an toàn sẽ làm cho ứng dụng của bạn dễ bị khai thác hơn. Việc tận dụng những ứng dụng đã có và cộng với một khối lượng code-base của nó khá lớn dễ dẫn đến bạn không hiểu và mất kiểm soát hay tệ hơn là có cả nguy cơ bảo mật bên trong những thư việc này.

Cách phòng tránh

  • Nên rà soát và remove những libraries, tính năng, files không cần thiết.
  • Subscribe và theo dõi những lỗi bảo mật để kịp thời upgrade những components.

A10: Insufficient Logging & Monitoring

Việc thiếu log hay monitoring không đầy đủ sẽ cho phép Attacker "đi dạo" đến rất nhiều nơi trong hệ thống của bạn, ngược lại, nếu có đầy đủ monitoring, logging, và việc Attacker đã tấn công 1 hoặc vài service ban đầu sẽ được phát hiện và nhanh chóng ngăn chặn.

Cách đề phòng

  • Audit những sự kiện như failed login, service side input validation failures.
  • Bảo đảm việc ghi log theo một định dạng chung để dễ quản lý và phân loại.
  • Ghi nhận những high-value transactions hay slow query lại để kiểm tra.

References:

Tools

  • Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts
  • owasp zap
  • nikto
  • kali linux
  • ssllabs

Quiz

Bạn thấy bài viết này như thế nào?
0 reactions

Comments

admin
January 25

https://github.com/thenguyenit/blogs/wiki/The-Agile

Add new comment

Image CAPTCHA
Enter the characters shown in the image.
Câu nói tâm đắc: “Điều tuyệt với nhất trong cuộc sống là làm được những việc mà người khác tin là không thể!”

Related Articles

Xử lý các phát sinh trên không hề đơn giản. Không chỉ xử lý một lần mà còn phải test để đảm bảo hệ thống chạy đúng khi đã xử lý xong. Khi gặp phải yêu cầu này trong dự án, bạn nên list đầy đủ các vấn đề cũng như cách thức tiến hành để hạn chế ảnh hưởng đến vận hành của hệ thống hiện tại.

301 Redirect (Moved permanently) là một mã trạng thái HTTP ( response code HTTP) để thông báo rằng các trang web hoặc URL

Redirect 302 (MovedTemporarily) hay còn gọi là redirection 302, chuyển hướng tạm thời, gần giống với Redirection 301, di chuyển vĩnh viễn.

Ở các quốc gia trên Thế Giới hiện tại, để xây dựng một website áp dụng kiến trúc JAMstack Doanh Nghiêp phải bỏ ra ít nhất ~3.000$ hoặc hơn.