Dữ liệu vào không hợp lệ Theo OWASP Guide, dữ liệu vào không hợp lệ là một nhược điểm phổ biến được tìm thấy đa số trong các ứng dụng web.. Chúng ta sẽ khảo sát khả năng nguy hiểm tiềm t
Trang 2Bảo mật ứng dụng web
Bài viết duới đây sẽ trình bày những nguy
cơ và cách phòng tránh đối với những cuộc tấn công vào ứng dụng web
Dữ liệu vào không hợp lệ
Theo OWASP Guide, dữ liệu vào không hợp lệ là một nhược điểm phổ biến được tìm thấy đa số trong các ứng dụng web Dữ liệu vào hỏng dẫn đến đa số những sự tổn thương khác trong môi trường này
(http://www.owasp.org/index.php/Data_Validation)
Trước khi chúng ta xem làm thế nào để ngăn ngừa nhược điểm lan rộng trong toàn bộ website của bạn (soltution ??) Chúng ta sẽ khảo sát khả năng nguy hiểm tiềm tàng gây ra cho công việc của bạn, khi
dữ liệu vào hỏng cho phép hiểu được thành phần xử lý của bạn
Hình 1 là một sự miêu tả hợp lý của bốn đường dữ liệu vào được tiếp nhận bởi một ứng dụng
Trang 3Làm thế nào một ứng dụng truy xuất, xử lý và hiển thị dữ liệu vào từ một trong số những tác động trực tiếp
Ví dụ : kẻ tấn công có thể them vào, xoá đi, hoặc tinh chỉnh những tham số URL trong chuỗi truy vấn Những trường biểu mẫu ẩn có thể
bị thay đổi và được xem xét lại Thông tin cở sở dữ liệu, đặc biệt là những trường được ghi bởi những ứng dụng khác, có thể là sự cố ý hoặc do một sự hư hỏng tình cờ
Khả năng tổn thương tiềm tàng
Ở đây có nhiều tác động phủ nhận hợp lý, nếu dữ liệu đưa vào chứa đựng sự định dạng không thích hợp hay nội dung không hợp lệ /tinh vi nắm bắt tình trạnh nguy kịch của ứng dụng web Quan sát một vài trường hợp sau :
***Hiển thị nội dung HTML sai
Kết quả sự hiển thị tác động không đầy đủ sẽ là một sự miêu tả không hoàn chỉnh website của bạn Nói cách khác, nhìn vào phần cuối của hình minh hoạ, dữ liệu vào hỏng có thể làm cho các lỗi của website bạn bị phơi bày ra Hơn nữa, những người tấn công có thể khai thác lỗi
ở đầu ra của ứng dụng để cần cù thu thập một vài ý tưởng, mặc dù người phát triển đã thận trọng trong cách code của mình Nếu kẻ tấn công đã dễ dàng có được những thông tin, thì cam đoan rằng đó sẽ là điều dễ dàng cho việc bẻ khoá những thành phần ứng dụng khác
***Bỏ qua sự xác nhận từ phía người dùng
Kiểm tra tính đúng đắn thì không thật sự hợp lý, nó không quá khó cho người tấn công vô hiệu hoá một đoạn mã thực thi trên máy trạm, nhập
Trang 4vào form input một giá trị sai và sau đó chấp nhận biểu mẫu (submit the form ) Nếu nó kiểm tra từ phía server không đúng, server huỷ bỏ yêu cầu và ngưng thi hành của những dòng lệnh không hợp lệ, đó cũng là hai kết quả hợp lý
***Hệ thống thông qua mã nguồn
Những lĩnh vực đề mục không được thông qua có thể chứa mã nguồn HTML giống như <script>and<object> thực hiện mã bất ngờ
***Sự phát sinh của việc thông báo lỗi
Bằng sự bắt buộc thông báo lỗi các mã nguồn nào đó, kẻ tấn công có thể chứa trình ứng dụng, hệ điều hành và kết nối tạm thông tin về hệ thống của bạn Thông tin này thường được dùng ở giai đoạn đầu của
sự tấn công- foot printing http://en.wikipedia.org/wiki/Footprinting
***Tràn bộ nhớ trung gian
Những kẻ tấn công có thể sử dụng làm tràn bộ nhớ trung gian để phá huỷ 1 hệ thống hoặc thực hiện mã hiểm độc
http://en.wikipedia.org/wiki/Buffer_overflow
***Truy cập trái phép
Truy cập tập tin có thể bị thu được bởi sự vận dụng các đường dẫn Ví
dụ như, tiếp theo 1 đường dẫn là tới 1 tập tin mà người sử dụng cho phép truy cập:
Code:
<a href=”display.cfm?paper_id=235”>Customer List</a>
Bằng sự vận dụng giới hạn paper_id, kẻ tấn công có thể lấy thông tin tiềm năng thận trọng tới chỗ mà hắn không được cho phép truy cập chính thức
***SQL Injection
Loại tấn công này làm cho cơ sở dữ liệu của công ty không được phép sửa đổi, bỏ đi, hoặc bổ sung thêm dữ liệu Điều đó gây ra bởi kẻ tấn công bao gồm mã SQL trong dữ liệu vào đến trường biểu mẫu hoặc bởi vận dụng những chuỗi câu hỏi 1 cách trực tiếp 1 ví dụ có thể tìm thấy tại
http://en.wikipedia.org/wiki/Sql_injection
Sự phê chuẩn như 1 hàng rào phòng thủ
Đây là bảng kê tính chất có thể bị làm hư hỏng, nhưng nó không hoàn thành Những tính chất này chỉ bị giới hạn bởi khuyết điểm độc nhất của hệ thống của bạn và tính sáng tạo của kẻ tấn công
1/ Thông qua mọi vấn đề, kiểm tra theo yêu cầu của bạn và loại bỏ tất
cả
2/ Thực hiện mọi vấn đề trên nguồn mở Đây là lý do làm cho khách hàng nhanh chóng nhận được những dữ liệu không chính xác
3/ Làm thay đổi nguồn dữ liệu từ xác thực trở nên không chính xác Với các từ khoá khác, kiểm tra lại và đưa ra dữ liệu không đúng hoặc không thực hiện
Trang 5Ở đây có nhiều sự thay đổi để kiểm tra Các việc kiểm tra sự thực thi của bộ lọc bao gồm :
a.Kiểu dữ liệu (string,integer,etc.)
b.Tham số yêu cầu
c.Chuỗi cho phép
d.Chuỗi nhập vào có phù hợp với sự giới hạn chiều dài tối đa và tối thiểu hay không ?
e.NULL(ký tự rỗng ) có được cho phép không ?
f.Nếu là kiểu số, thì điều kiện để nhập vào có giới hạn trong phạm vi nào không?
g.Sự sao lại dữ liệu nhập vào có được chấp nhận không? Nếu được chấp nhận thì nó thực thi được không?
h.Chuẩn yêu cầu được nhập vào (khi dùng để so sánh một biểu thức thông thường )
i.Nếu so sánh từ danh sách, thì tham số có bao gồm một giá trị hợp lý không?
4.Cần xem xét lại đoạn mã thực thi bên trong hay “buddy checks” Lập trình viên của bạn cần kiểm tra từng cú pháp trong tuyến phòng thủ đầu tiên
5.Chắc chắn rằng chất lượng của tiến trình xử lý được bảo đảm bao gồm cả việc kiểm tra, không những chỉ những giá trị hợp lệ mà còn cả những giá trị không hợp lệ
Sự thông qua một vài triển khai cung cấp những điều kiện tự vận hành VD: những dữ liệu đã được xác nhận, đồng ý trong ASP.NET
+Yêu cầu trường chỉ báo –giá trị rổng
+So sánh sự đúng đắn –So sánh giá trị nhập vào
+Phạm vi hợp lệ-so sánh yêu cầu nhập vào với sự ràng buộc phạm vi +Xác nhận biểu thức thông thường –cho phép người dùng nhập biểu thức thông thường
+Thói quen thông thường –cho phép khởi tạo những sự lựa chọn thông thường
Theo HVA Online