Trong khoảng vài năm trở lại đây, số lượng các lỗ hổng bảo mật của các trình ứng dụng Web được công bố tăng lên một cách đáng kể. Những người làm bảo mật thường chỉ quan tâm đến độ bảo mật của mạng và hệ điều hành chứ ít quan tâm nhiều đến bảo mật của chính các ứng dụng chạy trên máy chủ web.
Thống kê gần đây của Netcraft cho thấy hơn 65% các cuộc tấn công được thực hiện qua cổng (port) 80 của TCP, cổng truyền thống của Web.
Xin giới thiệu với các bạn một tài liệu khá hay về bảo mật ứng dụng Web được trình bày tại Hội thảo bảo mật thông tin mạng máy tính do HVA tổ chức vào tháng 7/2003 - bài của UFO (Ng Minh Thắng) thành viên Cộng đồng An ninh mạng HVA. Hy vọng tài liệu này sẽ giúp mọi người hiểu về các vấn đề bảo mật cố hữu trong các trình ứng dụng Web và cách xây dựng các trình ứng dụng Web, dịch vụ Web bảo mật.
Tại sao lập trình viên lại viết chương trình kém bảo mật?
Nhiều lập trình viên không chủ ý viết những đoạn mã kém bảo mật, nhưng thực tế họ lại làm vậy. Có nhiều nguyên nhân dẫn đến việc này. Có một bài viết trên BugTraq đã tổng kết lại như sau:
Không có chương trình học về bảo mật máy tính trong hầu hết các trường học. Ngay cả khi có chương trình học về bảo mật, chúng thường cũng không thảo luận về cách viết một chương trình có độ bảo mật cao mà thường chỉ tập chung vào một phần nào đó, ví dụ như mật mã hoá. Chúng không đề cập đến các vấn đề thực tế như tràn bộ đệm ( Buffer Overflow), kiểm tra dữ liệu đầu vào
Các sách dạy lập trình không dạy về các kĩ thuật lập trình an toàn, bảo mật
Hầu hết mọi người không sử dụng các phương pháp kiểm tra chính thống
Lập trình viên là con người và con người thì thường là lười biếng. Vì thế các lập trình viên thường chọn các phương pháp tiếp cận dễ dàng thay vì các cách tiếp cận bảo mật
Hầu hết các lập trình viên không phải là lập trình viên tốt
Hầu hết các lập trình viên không phải là những người làm về bảo mật. Họ không suy nghĩ như một kẻ tấn công thường nghĩ
Còn rất nhiều phần mềm cổ lỗ có nhiều lỗ hổng bảo mật. Sửa chữa những phần mềm này là một việc khó khăn
Hầu hết khách hàng không quan tâm đến bảo mật
Bảo mật đòi hỏi thêm thời gian phát triển
Bảo mật đòi hỏi thêm thời gian kiểm thử
Cần bảo mật đến mức nào?
Khi nói về độ bảo mật của một chương trình Web, một câu hỏi thông minh sẽ là “Dự án này cần bảo mật đến mức nào”. Phần mềm thường được tạo ra để thỏa mãn các yêu cầu về tính năng trước, sau đó mới đến bảo mật. Tuy nhiên khoảng thời gian thiết kế và phát triển chương trình là lúc lý tưởng đê xác định yêu cầu về bảo mật và tích hợp nó vào chương trình. Phòng bệnh hơn chữa bệnh.
Vậy làm sao để biết được bảo mật đến mức nào là phù hợp. Cần nhấn mạnh vài điểm quan trọng sau đây:
Không thể loại bỏ hết rủi ro
Chỉ có thể hạn chế rủi ro
Đừng bỏ quá nhiều chi phí vào bảo mật với những website không đáng giá. Tránh tình trạng “Một tiền gà ba tiền thóc”
Không bao giờ có thể loại bỏ được hết rủi ro. Mục đích bảo mật cho một hệ thống là xác định được mức độ bảo mật cần thiết để trình ứng dụng có thể hoạt động tốt trong môi trường của nó.
Quan điểm thứ hai là luôn có nhiều cách để giảm thiểu độ rủi ro. Tài liệu này đề cập chủ yếu đến các biện pháp đối phó trên phương diện kĩ thuật như kiểm tra dữ liệu đầu vào, đầu ra.
Những nhà thiết kế cần phải hiểu rõ họ đang bảo mật cho cái gì. Việc xác định đâu là những phần tử thông tin trọng yếu cũng là một công việc quan trọng trong việc thiết kế trình ứng dụng Web. Người dùng luôn phải trả giá cho bảo mật, cả về tốc độ và chi phí.
Những nguyên tắc về bảo mật
Những nguyên lý chung về bảo mật dưới đây là rất hữu dụng khi thiết kế hệ thống
Kiểm tra đầu ra và đầu vào
Tất cả dữ liệu đầu vào và đầu ra phải được kiểm tra để chắc chắn rằng nó là hợp lệ. Một chiến lược hợp lý là chỉ chấp nhận những dữ liệu với những tính chất cho trước và hủy bỏ tất cả những dữ liệu khác.
Giữ cho hệ thống đơn giản
Khi cố gắng xây dựng một hệ thống bảo mật, nếu nó trở nên quá khó sử dụng đối với người dùng, nó sẽ không được sử dụng nữa. Thông thường cách bảo mật hiểu quả cũng là cách đơn giản nhất. Đừng bắt người dùng phải nhập mật mã đến 12 kí tự hay bắt người quản trị hệ thống phải thiết lập hàng núi những thiết lập bảo mật.
Độ bảo mật của hệ thống là độ bảo mật ở chỗ yếu nhất
Nhiều Website thường quảng cáo "Hệ thống này bảo mật 100%, nó dùng 128bit SSL". Dù cửa chính của bạn chắc đến đâu mà cửa sau lại để lỏng lẻo thì cũng chẳng có ý nghĩa gì. Những kẻ tấn công luôn tìm điểm yếu nhất và tấn công vào đó.
Quyền thấp nhất
Hệ thống phải được thiết kế theo cách mà nó được chạy với quyền hệ thống thấp nhất đủ để cho hệ thống hoạt động. Nếu ứng dụng không cần đến quyền root thì đừng bao giờ gán quyền đó cho nó.
Chứng thực người dùng
Chứng thực người dùng là gì ?
Trong một trình ứng dụng Web, rất dễ lẫn lộn giữa chứng thực người dùng và quản lí phiên làm việc. Chứng thực người dùng là quá trình xác định xem một người dùng hay một thực thể có đúng là người mà anh ta/cô ta tuyên bố là hay không ?
Người dùng thường được chứng thực bằng username và password. Sau khi được chứng thực, một dấu hiệu của phiên làm việc thường được đặt vào trình duyệt của người dùng (được lưu trong cookie). Điều này cho phép trình duyệt gửi dấu hiệu phiên làm việc mỗi khi một yêu cầu được thực hiện, cho phép chứng thực thực thể đó với server. Người dùng thông thường chỉ cần chứng thực một lần trong mỗi phiên làm việc, nhưng việc chứng thực thực thể thì xảy ra trong mỗi yêu cầu (request).
HTTP Basic Authentication
Có nhiều cách để chứng thực người dùng. Cách đơn giản nhất là dùng HTTP Basic Authentication. Khi được yêu cầu được thực hiện với một URI, máy chủ Web trả lời trình duyệt mã 401.
HTTP/1.1 401 Authorization Required
Điều này bảo trình duyệt phải cung cấp một username và password. Trình duyệt yêu cầu người dùng nhập username và password, thường ở trong một hộp thoại. Trình duyệt nối username và password lại, ngăn nhau bởi dấu hai chấm và sau đó mã hóa base 64 xâu này. Yêu cầu thứ hai sẽ được yêu cầu với cùng địa chỉ URI này trong đó xâu username và password đã mã hóa sẽ được gửi kèm trong header.
Một vấn đề trong cách chứng thực này là không có cách nào để bắt trình duyệt “logout”.
Username và password sẽ được truyền trên mạng mà không được bảo vệ trừ phi SSL hoặc TLS được sử dụng.
Chứng thực dựa trên form
Thay vì chứng thực người dùng ở mức giao thức, các trình ứng dụng Web có thể sử dụng mã của chính bản thân mình. Người lập trình có thể yêu cầu người dùng chứng thực thông qua một HTML FORM.
Tất nhiên phương thức chứng thực thông qua HTML FORM cần phải có những biện pháp bảo vệ trước những cách tấn công cổ điển dựa trên giao thức được mô tả ở đây và phải có cách mã hóa hợp lý các mật mã được lưu trong cơ sở dữ liệu.
Chú ý: Các form khi được gửi đi dưới dạng POST hoặc GET sẽ gửi username và password dưới dạng text, trừ phi SSL được sử dụng.
Các vấn đề cơ bản của việc chứng thực
Lưu trữ Username và Password
Trong các hệ thống thông tin mà việc chứng thực được dựa trên Password, hệ thống phải có cách lưu trữ Usernames và Passwords một cách hợp lý. Passwords phải được lưu trữ sao cho trình ứng dụng có thể tính và so sánh mật mã trong cơ sở dữ liệu với mật mã do người dùng cung cấp, nhưng password trong CSDL không thể đọc được bởi nhà quản trị hay kẻ tấn công. Các thuật toán mã hóa một chiều (hash) như MD5 có thể đảm đương tốt vai trò này.
Đảm bảo chất lượng của password
Một mật mã tốt là mật mã không thể đoán được. Một mật mã như vậy nên có ít nhất 8 kí tự và có cả kí tự chữ và số.
Khóa account
Một cách đoán mật mã thường gặp là thử một số lượng lớn các mật mã khác nhau. Hệ thống nên khóa account sau một số lần đăng nhập không thành công nhất định. Con số thích hợp có thể là năm.
Có một trở ngại trong kĩ thuật này. Kẻ tấn công có thể thử một số lượng lớn các mật mã trên một danh sách người dùng đã biết trước, điều này có thể dẫn tới việc khóa toàn bộ danh sách người dùng. Vì thế việc khóa account chỉ nên khóa trong một thời gian ngắn, ví dụ là 15 phút. Thời gian này cũng đủ để cho việc đoán password phải cần một thời gian dài không thể chấp nhận được, trong khi cho phép mở account với những người dùng hợp lệ.
Thay đổi mật mã theo định kì
Việc bắt người dùng thay đổi mật mã sau một khoảng thời gian nhất định là một cách tốt để tránh việc bị lộ mật mã.
Quản lí phiên làm việc của người dùng
HTTP là một giao thức phi trạng thái, có nghĩa là server trả lời từng yêu cầu đơn lẻ của client mà không liên kết chúng với nhau. Cần phải sử dụng một kĩ thuật quản lí trạng thái để cho phép các yêu cầu của người dùng được gắn với một “phiên làm việc”. Việc có thể gắn các hành động của người dùng với một phiên làm việc cụ thể là rất quan trọng với bảo mật một chương trình Web. Việc quản lí phiên làm việc kém có thể dẫn đến việc các tài khoản của người dùng bị đánh cắp, trong nhiều trường hợp kẻ tấn công còn có thể có quyền quản trị hệ thống.
Các mô hình quản lí phiên làm việc
Session Time-Out
Phiên làm việc không bao giờ hết hạn sẽ cho phép kẻ tấn công có thời gian vô hạn để đoán hoặc brute force (thử toàn bộ) một phiên làm việc hợp lệ đã được chứng thực. Một ví dụ cụ thể là tùy chọn “Remember Me” có trong rất nhiều Website. Nếu cookie của một người dùng bị đánh cắp hoặc brute-force, kẻ tấn công có thể dùng phiên làm việc tĩnh này để truy nhập vào account của người dùng đó. Thêm vào đó, các dấu hiệu của phiên làm việc có thể được cache trên proxy servers, và nếu server đó bị đột nhập thì những thông tin như vậy có thể bị anh ta lợi dụng nếu phiên làm việc đó chưa hết hạn.
Phát hiện phiên làm việc giả mạo/tấn công Brute-Force
Nhiều Website sử dụng các phương pháp để ngăn chặn việc đoán mật khẩu ( ví dụ nó có thể tạm thời khóa account đó hoặc ban địa chỉ IP dùng để tấn công). Một kẻ tấn công có thể thử hàng trăm hoặc hàng nghìn lần các dấu hiệu phiên làm việc khác nhau được gắn trong URL hoặc cookie. Biện pháp ngăn chặn là tạm thời ban địa chỉ IP hoặc khóa account đó lại. Cũng nên cài đặt thêm các module phát hiện để phát hiện xem một người dùng đã được chứng thực nào đó đang cố gắng thực hiện việc leo thang đặc quyền.
Chứng thực lại phiên làm việc
Những hoạt động quan trọng của người dùng như chuyển tiền nên yêu cầu người dùng chứng thực lại trước khi thực hiện hành động đó. Phương pháp này khá hiệu quả để chống lại các phương pháp tấn công kiểu như Cross Site Scripting.
Truyền dấu hiệu của phiên làm việc
Khi các dấu hiệu của phiên làm việc (e.g cookies) được truyền đi trên mạng, các dấu hiệu này có thể bị đánh cắp. Hệ thống nên sử dụng các biện pháp mã hóa để ngăn chặn chuyện này. SSL và TLS là các biện pháp hữu hiệu để bảo vệ các dấu hiệu của phiên làm việc.
Log sự kiện
Log là rất quan trọng trong việc cung cấp những thông tin bảo mật về một chương trình Web và các phần mềm liên quan. Lưu lại thông tin về các cuộc truy nhập là rất quan trọng vì những nguyên nhân sau đây:
Logs thường là nơi duy nhất lưu giữ lại những hành vi truy nhập đáng ngờ
Logs có thể cung cấp những thông tin cụ thể về hoạt động của một người dùng
Logs rất hữu dụng để biết chuyện gì đã xảy ra sau khi có trục trặc, dù có liên quan đến bảo mật hay không. Thậm chí việc này còn giúp nhà quản trị biết được kẻ đột nhập đã làm những gì và qua đó có các biện pháp khắc phục thích hợp
Logs trong một số trường hợp còn dùng để làm bằng chứng. Trong trường hợp này thì khỏi phải nói logs quan trọng đến như thế nào
Log những thành phần nào?
Khi log lại thông tin, nên lưu lại các thông tin gỡ rối cần thiết như thời gian xảy ra sự kiện, người thực hiện và mô tả chi tiết về sự kiện đó. Những sự kiện sau đây nên được logs lại trong trình ứng dụng:
Đọc dữ liệu
Ghi dữ liệu
Sửa những đặc tính dữ liệu quan trọng như là quyền truy nhập, quyền sở hữu thông tin
Xóa dữ liệu
Các sự kiện chứng thực người dùng (đăng nhập, đăng xuất,…).
Các hoạt động quản trị Website (quản lí người dùng, xem thông tin người dùng,…).
Quản lí logs
Cần phải có cách quản lí hiệu quả logs để khả năng log của Web server và trình ứng dụng không bị bỏ phí. Việc lưu trữ, quản lí thông tin logs kém hiệu quả sẽ khiến cho những thông tin này có thể bị xâm hại và trở nên vô dụng cho việc phân tích bảo mật sau này.
Những file logs nên có thuộc tính sao cho chỉ có thể ghi thông tin mới mà không thể xóa thông tin cũ đi. Các logs files cũng nên được backup thường xuyên.
Kiểm tra dữ liệu
Hầu hết những kiểu tấn công thường gặp ( sẽ được mô tả trong phần sau) có thể được ngăn chặn hoặc giảm bớt đáng kể bằng cách kiểm tra đầu vào một cách hợp lý. Việc kiểm tra dữ liệu là một yếu tố quan trọng nhất trong việc thiết kế một ứng dụng bảo mật. Nói đến kiểm tra dữ liệu tức là kiểm tra cả dữ liệu đầu vào và dữ liệu đầu ra.
Các chiến lược kiểm tra
Các chiến lược kiểm tra đầu vào chịu ảnh hưởng lớn của kiến trúc chương trình. Có 3 mô hình để lựa chọn khi thiết kế một chiến lược kiểm tra dữ liệu:
Chỉ chấp nhận những dữ liệu đã biết chắc là hợp lệ
Loại bỏ những dữ liệu biết chắc là không hợp lệ
Chỉnh sửa những dữ liệu có hại
Cần phải nhấn mạnh rằng chiến lược đầu tiên là chiến lược hiệu quả nhất. Tuy nhiên không phải lúc nào cũng thực hiện được điều này vì những lí do tài chính cũng như kĩ thuật.
Cả ba phương thức đều phải kiểm tra:
Kiểu dữ liệu
Cú pháp
Độ dài
Lưu ý: Không bao giờ được dựa vào sự kiểm tra dữ liệu đầu vào ở client-side.
Mọi sự kiểm tra ở client-side đều có thể bị vượt qua. Mọi sự kiểm tra dữ liệu đều phải được thực hiện bên phía server. Việc kiểm tra dữ liệu bên phía client-side, với mục đích làm cho chương trình thân thiện hơn, là có thể chấp nhận được nhưng không thể coi là một quá trình kiểm tra thực sự. Mọi sự kiểm tra phải được thực hiện bên phía server, ngay cả khi phải lặp lại các thao tác kiểm tra đã thực hiện bên phía client-side.
(Ng Minh Thắng – UFO - HVA Member)
Source Bảo mật ứng dụng Web (Secure Web Application)
NHÀ CUNG CẤP DỊCH VỤ CHUYÊN NGHIỆP
PHÁT TRIỂN
WEBDESIGN - HOSTING - DOMAIN
Bài đăng
