Web Application Security. - .:: HVAOnline ::.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

Web Application Security.

[Question] Web Application Security.	08/08/2006 21:30:16 (+0700) \| #1 \| 13221

NguyenTracHuy
HVA Friend

Joined: 08/08/2003 15:34:40
Messages: 388
Offline

Web Application Security

Unvalidated Input

According to the OWASP Guide, unvalidated input is the most common weakness found in web applications. Tainted input leads to almost all other vulnerabilities in these environments (OWASP, 2005). Before we look at how to prevent this weakness from spreading throughout your web solutions, let’s examine the potential threats to your business when tainted input is allowed to reach your processing components.
Figure 1 is a logical view of four of the ways in which input is received by an application

bmuht_gpj.95954_04f04b3d3faae05313657ae64562e690/5/8/6002/daolpu/enilnoavh/ten.murofavh//:ptth

Input from any one of these sources impacts how an application accesses, processes, and displays data. For example, attackers might add, delete, or modify URL parameters in a query string. Hidden form fields can be changed and the form resubmitted. Database information, especially fields written by other applications, might be either purposely or accidentally tainted.
Potential Vulnerabilities
There are many possible negative outcomes if input containing either improperly formatted or invalid/malicious content reaches a business critical web application. The following are just a few:
Improper HTML display – The lowest impact display issue would be an unprofessional portrayal of your site. On the other end of the spectrum, tainted input can render your display unusable. Further, attackers can force errors in application output to gain some idea of the diligence with which your developers tighten-up their code. If it’s easy to hack a display, it’s a good bet that it’s just as easy to crack other application components.
By-passed client side validation – Client side validation is not really validation. It isn’t very difficult for an attacker to disable script execution on her workstation, enter malicious invalid form input, and then submit the form. If there’s no validation on the server side of the transaction, server crashes and the execution of rogue commands are just two of the possible outcomes.
Cross-site scripting – Text fields that are not validated might contain HTML tags--like <script> and <object>--that execute code unexpectedly.
Generation of informational error messages – By forcing certain types of error messages, an attacker can obtain application and operating system version and patch level information about your system. This information is commonly used in the first phase of an attack—footprinting.
Buffer overflow – Attackers can use buffer overflows to crash a system or to execute malicious code.
Unauthorized access – Access to files might be obtained by manipulating paths. For example, the following is a path to a file to which the user has authorized access:
<a href=”display.cfm?paper_id=235”>Customer List</a>
By manipulating the paper_id parameter, an attacker could potentially retrieve sensitive information to which he has not been granted official access.
SQL Injection – This type of attack exposes company databases to unauthorized modification, deletion, or addition of data. It’s caused by an attacker including
Input from any one of these sources impacts how an application accesses, processes, and displays data. For example, attackers might add, delete, or modify URL parameters in a query string. Hidden form fields can be changed and the form resubmitted. Database information, especially fields written by other applications, might be either purposely or accidentally tainted.
Potential Vulnerabilities
There are many possible negative outcomes if input containing either improperly formatted or invalid/malicious content reaches a business critical web application. The following are just a few:
Improper HTML display – The lowest impact display issue would be an unprofessional portrayal of your site. On the other end of the spectrum, tainted input can render your display unusable. Further, attackers can force errors in application output to gain some idea of the diligence with which your developers tighten-up their code. If it’s easy to hack a display, it’s a good bet that it’s just as easy to crack other application components.
By-passed client side validation – Client side validation is not really validation. It isn’t very difficult for an attacker to disable script execution on her workstation, enter malicious invalid form input, and then submit the form. If there’s no validation on the server side of the transaction, server crashes and the execution of rogue commands are just two of the possible outcomes.
Cross-site scripting – Text fields that are not validated might contain HTML tags--like <script> and <object>--that execute code unexpectedly.
Generation of informational error messages – By forcing certain types of error messages, an attacker can obtain application and operating system version and patch level information about your system. This information is commonly used in the first phase of an attack—footprinting.
Buffer overflow – Attackers can use buffer overflows to crash a system or to execute malicious code.
Unauthorized access – Access to files might be obtained by manipulating paths. For example, the following is a path to a file to which the user has authorized access:
<a href=”display.cfm?paper_id=235”>Customer List</a>
By manipulating the paper_id parameter, an attacker could potentially retrieve sensitive information to which he has not been granted official access.
SQL Injection – This type of attack exposes company databases to unauthorized modification, deletion, or addition of data. It’s caused by an attacker including

[Question] Re: Web Application Security.	08/08/2006 21:31:53 (+0700) \| #2 \| 13223

NguyenTracHuy
HVA Friend

Joined: 08/08/2003 15:34:40
Messages: 388
Offline

Bảo mật ứ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
bmuht_gpj.95954_04f04b3d3faae05313657ae64562e690/5/8/6002/daolpu/enilnoavh/ten.murofavh//:ptth
Là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 tì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 và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.
--Ở đâ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.

Người dịch :NguyenTracHuy-Nhóm dịch thuật HVA

Go to:

Users currently in here
1 Anonymous