Bảo mật ứng dụng web

Bảo mật trong ứng
dụng web
Nguyễn Thế Vinh
Công ty cổ phần Con Tự Học
http://www.contuho.com

Nội dung
• Giới thiệu các lỗ hổng thường gặp
• Demo khai thác một số lỗ hổng
• Cách phòng chống các lỗ hổng
• Công cụ ra quét

Sony Pictures bị hack (2011)

Các sân bay ở Việt Nam 2016

Tại sao phải bảo mật ứng dụng Web
• Web Application là mục tiêu số 1 của các hacker
 75% các cuộc tấn công nhằm vào tầng Application (Gartner)
• Hầu hết các Web Application đều có lỗ hổng
 95% Web Application có lỗ hổng (Imperva)
 78% Web App có lỗ hổng dễ khai thác (Sysmantec)
 67% Web App bị lợi dụng để phát tán Malware (Sysmantec)

Các lỗ hổng thường
gặp

Injection
• Nhân tố
 Bất cứ ai, hệ thống nào có thể gửi dữ liệu không tin cậy vào hệ thống
• Khả năng tấn công
 DỄ
• Độ phổ biến
 Phổ biến
• Khả năng phát hiện
 Trung bình
• Mức độ ảnh hưởng
 Nghiêm Trọng: đánh cắp, phá hủy dữ liệu…

Injection (tiếp)
• Injection là?
 Đánh lừa ứng dụng, nhằm tiêm một hay nhiều đoạn code, câu lệnh ngoài ý
muốn vào chương trình.
• Các loại Injection
 SQL
 LDAP
 OS Command
 Xpath
 …

SQL Injection
http://www.sample.com?SampleID=1
“SELECT * FROM Sample WHERE SampleID=1”
http://www.sample.com?SampleID=1; DROP TABLE Product
“SELECT * FROM Sample WHERE SampleID=1; DROP TABLE
Product”

Injection: Cách phòng chống
• Hạn chế dùng command text
 Nếu dùng thì nên dùng SqlParameter
• Sử dụng Stored Procedured
 Lưu ý các trường hợp build query động trong stored
• Escape tất cả các dữ liệu đầu vào
• Phân quyền (user sql) mức thấp nhất có thể
• White list input validation
 VD: Tên chỉ chấp nhận [A-Za-z ]

Broken authentication &
Session Management
• Các chức năng authentication, authorization được thi công không
đúng khiến attacker dễ dàng đánh cắp mất khẩu, quyền truy cập (tạm
thời hoặc vĩnh viễn)

Session Management
• Cookie: authenticated=1

Session Management
• Kiểm tra thông tin đăng nhập:
 Session[“UserName”] != null

Session Management
• HTTP là protocol không có trạng thái (stateless protocol)
 Đơn giản chỉ có: HTTP request, HTTP response
 Tất cả dữ liệu luôn được gửi qua HTTP Request
• Làm thế nào để lưu giữ trạng thái?
 Client: cookies
 Server: sessions
• Các ứng dụng thướng lưu trữ SessionID trong cookie, URL
 Vấn đề: Mất SessionID là  mất mật khẩu
• Nhiều cách để đánh cắp SessionID
 packet sniffing – (Wifi công cộng)
 HttpReferrer logs, if sessionId is in the URL

Session Management

Session Management
• Sử dụng SSL!
 Sniff Cookies (session ID) khó khắn hơn
 Nếu không sử dụng SSL ở mọi nơi được thì hãy dùng ở form login
• Sử dụng httponly cookie
• Thiết lập timeout cho session, cookie
 Hủy session khi logout
• Không sử dụng mode SessionID qua URL, mà dùng cookie
• Mã hóa cookie nếu cần thiết
• Không ghi session ID ra log.
• Kiểm tra password cũ khi đổi. Gửi email xác nhận tới email cũ nếu
đổi email

Cross-Site Scripting (XSS)
• Cho phép Attacker có thể thực thi một đoạn Script trên trình duyệt
của Victim. Để đánh cắp cookie (session id), thay đổi giao diện trang
web nhằm mục đích lừa đảo, dẫn người dùng đến trang web chứa
malware…
• Gần như website nào cũng có lỗ hổng này

Cross-Site Scripting (XSS)
• Stored XSS
 Thông qua các tính năng cho phép nhập liệu không được validate attacker
nhập các đoạn mã và được lưu giữ vào chương trình.
• Reflected XSS
 Tiêm mã thông qua URL

XSS – Cách phòng chống
• Tuyệt đối không bao giờ tin tưởng dữ liệu người dùng nhập vào
• “Escape” tất cả dữ liệu trước khi hiển thị ra
 JavaScript parameters, URL parameters, STYLE elements
 Remove script tags, and possibly anything with a SRC attribute
• Không dùng HTTP GET cho các request thay đổi dữ liệu
 Không thì 1 thẻ IMG cũng có thể xóa nội dung trên web
• Sử dụng HttpOnly để bảo vệ cookie
• Built-in protection
 ASP.NET Request Validation (ASP.NET 4.0)
 AntiXSS library (ASP.NET 4.5)
• NWebSec

XSS – Validation & Encoding every
where

Insecure Direct Object Reference
• Tham khảo một ví dụ
 http://www.company.com/employeeprofile.aspx?id=emp1
 Tính năng xem và chỉnh sửa thông tin cá nhân của mỗi nhân viên
 Lập trình viên không dùng ID của user hiện tại mà lại lấy qua URL
 => Employe 1 có thể xem
http://www.company.com/employeeprofile.aspx?id=emp2
• Phân quyền chỉ ẩn menu chức năng, nhưng khi truy cập bằng đường
dẫn vẫn vào được.

Insecure Direct Object Reference
Cách phòng chống
• Chỉ phân quyền, hạn chế ở Front-end là chưa đủ
• Tất cả các tài nguyên phải được chỉ định mức độ an ninh và được
kiểm tra quyền
• Lưu ý các API lấy dữ liệu rất dễ bị lãng quên check quyền.

Security Misconfiguration
• Bảo mật tốt là ta phải bảo mật ở tất cả các tầng
 Application (Source Code)
 Application Server (OS)
 Web Server
 Database server
 …
• Thông thường thiết lập mặc định của các tầng, ứng dụng thường kém bảo
mật
 Default password
 FTP Anonymous
 Directory listing
 Error page
 Permission
 MIME Type
 Unused port open

Security Misconfiguration
• Đọc kỹ tài liệu hướng dẫn của các phần mềm khi triển khai
• Chịu có theo dõi các tạp chí, blog công nghệ để cập nhật các thông tin
về bảo mật
• Dùng phần mềm quét hệ thống
 Microsoft Baseline Security Anlyzer …
• Disable tất cả các port không dùng
• Disable, đổi password mặc định
• Không show báo lỗi chi tiết đến người dùng cuối
 Custom Errorpage

Sử dụng phần mềm, component có lỗ
hổng
• Luôn cập nhật bản mới nhất có thể
• Theo dõi website của hãng để có thông tin về lỗ hổng, bản vá sớm
nhất
• Không sử dụng phần mềm crack, hay dùng phần mềm không rõ
nguồn gốc trên server.

Upload
• Attacker có thể upload 1 trang mã nguồn (aspx, php), virus, backdoor
lên server, dựa vào tính năng upload không validate.
• Lỗ hổng này rất nghiêm trọng, Attacker có thể chiếm toàn quyền
kiểm soát server thông qua lỗ hổng này
• Developer mới nào code tính năng upload hầu như cũng mắc phải lổ
hổng này.

Upload – Cách phòng chống
 Validate ui chưa đủ
 Kiểm tra header file
 Không dùng tên file truyền từ client lên
 Validate đuôi file hợp lệ
 Cài phần mềm virus lên server
 Tính năng upload nên viết, kiểm nghiệm và đóng gói thành các thư viện
dùng chung.

Download
• Attacker có thể download các file nhạy cảm từ server
 Các file config
 Mã nguồn
• Developer mới nào code tính năng download hầu như cũng mắc phải
lổ hổng này.

Download – Cách phòng chống
• Không sử dụng filename truyền từ phía client
 Nên sử dụng ID thông qua các bảng quản lý
• Nếu vẫn sử dụng thì remove hết các ký tự “..”
• Kiểm tra đuôi file, chỉ cho phép dowload những file có đuôi trong
danh sách được phép.

OWASP
• OWASP (Open Web Application Security Project) là 1 dự án mở về
bảo mật ứng dụng web, dự án là sự cố gắng chung của cộng đồng với
mục đích giúp các doanh nghiệp có thể phát triển, mua và bảo trì các
ứng dụng web một cách an toàn. OWASP cung cấp cho công đồng
nhiều nguồn “tài nguyên” khác nhau:
 Công cụ và tiêu chuẩn về an toàn thông tin
 Các bộ chuẩn về kiểm tra bảo mật ứng dụng, lập trình an toàn và kiểm
định mã nguồn
 Các thư viện và tiêu chuẩn điều khiển an toàn thông tin
 Các nghiên cứu mới nhất về bảo mật ứng dụng web
 Các maillist uy tín về thông tin bảo mật

Một vài projects của OWASP
Zed Attack Proxy (ZAP)
Easy to use integrated penetration testing tool for finding
vulnerabilities in web applications
Security Shepherd
CBT application for web and mobile application security awareness
and education
Dependency Check
Utility that identifies project dependencies and checks if there are any
known, publicly disclosed, vulnerabilities
O-Saft
Tool to show information about SSL certificates and tests the SSL
connections for given list of ciphers and various configurations
Source: https://www.owasp.org

OWASP vs CWE/SANS
Both are like
different sides of the
same coin
PCI DSS points to
both as industry best
practices
Optimal: Be familiar
with both!
OWASP
Top 10
CWE/SANS
Top 25
Source: http://www.docstoc.com/docs/115032367/2010-CWESANS-Top-25-with-OWASP-Top-10-and-PCI-DSS-V2-Mapping

Các phần mềm sử dụng phát hiện
sớm lỗ hổng
• CAT.NET
• OWASP Dependency Check
• Burp suite
• Acunetix
• MBSA – Microsoft baseline security analyzer

Bảo mật ứng dụng web

More Related Content

What's hot

Similar to Bảo mật ứng dụng web

Bảo mật ứng dụng web