<![CDATA[Latest posts for the topic "Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn"]]> /hvaonline/posts/list/12.html JForum - http://www.jforum.net Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn I. Giới thiệu Nhận biết lỗi ứng dụng Web thông qua quá trình quan sát mã nguồn không phải là một quá trình đơn giản. Mã nguồn của một ứng dụng Web vô cùng phức tạp bao gồm nhiều thành phần (biến, hàm, đối tượng, lớp, …). Cho nên phải có phương pháp tiếp cận phù hợp thì mới có thể kiểm tra đánh giá an toàn ứng dụng Web một cách triệt để thông qua việc kiểm tra mã nguồn của ứng dụng đó. Một câu hỏi đơn giản là: “Người kiểm tra sẽ làm gì với mã nguồn Web ? Anh ta sẽ bắt đầu từ đâu ? Sẽ bắt đầu như thế nào ? … “. Có một số cách tiếp cận như: 1) Xây dựng một công cụ tự động scan toàn bộ mã nguồn và dựa trên tập nhận biết các điểm yếu để đưa ra cảnh báo cho người kiểm tra. 2) Nhận biết các điểm vào của ứng dụng và thực hiện tìm kiếm mối quan hệ giữa điểm vào của ứng dụng và mã nguồn ứng dụng. Ưu điểm của phương pháp 1 thì rất nhanh trong việc tìm kiểm tra. Nhưng nhược điểm lớn nhất của nó là không triệt để, vì chỉ đơn thuần dựa vào tập nhận biết điểm yếu ban đầu. Phương pháp thứ 2 thì triệt để hơn nhưng nhược điểm của nó là thời gian trong việc kiểm tra mặc dù trong quá trình tím kiếm mỗi liên hệ giữa điểm vào ứng dụng và mã nguồn có công cụ bổ trợ. Theo seamoun thì tốt nhất nên vận dụng cả hai. Sử dụng phương pháp 1 trước để nhận định sơ bộ về tình hình của mã nguồn. Liệt kê nhanh chóng các điểm yếu có thể có do công cụ nhận diện. Tiếp đến sử dụng phương pháp 2 để xác minh và tìm thêm các lỗi mới. Trong quá trình kiểm tra, theo seamoun thì phải đặt ứng dụng Web trong cái tổng thể của nó. Tức là tự bản thân một ứng dụng Web thì không thể chạy được nếu như thiếu các thành phần khác như máy chủ phục vụ web, database, … Nếu như đặt ứng dụng Web trong cái tổng thể của nó thì trước tiên chúng ta phải nhận diện những thành phần liên quan của nó. Nhận diện các thành phần liên quan ở đây là máy chủ phục vụ web, cở sở dữ liệu mà ứng dụng sử dụng và các thành phần bổ trợ khác ví dụ như tường lửa cho ứng dụng, tài nguyên khác, … Bước tiếp theo nhận diện các điểm vào của ứng dụng ? Điểm vào của ứng dụng là gì? Tức là thành phần mà ứng dụng Web tương tác (ví dụ như các phương thức GET/POST, các forms, chuỗi truy vấn, cookies,…) với người dùng cuối. Sau khi đã xác định tất cả các điểm vào của ứng dụng, bước tiếp theo sẽ thực hiện truy tìm mối liên hệ giữa các điểm vào của ứng dụng với mã nguồn Web sử dụng. Quá trình này rất quan trọng và điểm mấu chốt để tìm ra lỗi của ứng dụng. Nên có một công cụ bổ trợ để trợ giúp quá trình lần tìm mối liên hệ này. Công cụ bổ trợ này phải phù hợp với từng đặc thù mã nguồn ứng dụng Web. Bởi vì, hiện tại có rất nhiều mã nguồn phát triển ứng dụng Web (ASP.NET, PHP, Perl, JSP, …) nên cách tiếp cận nó cũng phải khác nhau về mặt cấu trúc mà từng ngôn ngữ sử dụng. Không thể một công cụ trace code cho ASP.NET lại dùng cho ngôn ngữ PHP được :D :D :D. Nếu như các công cụ bổ trợ này mà không phù hợp với việc trace code cho ứng dụng Web mà chúng ta đang kiểm tra thì chúng ta cũng phải “è cổ” code riêng một cái sử dụng riêng cho ứng dụng đó. Sau khi đã có được mối liên hệ giữa các điểm vào của ứng dụng thì nên biểu diễn nó bằng sơ đồ quan hệ (dùng hình vẽ hay ký hiệu gì thì tùy miễn sao biểu diễn được mối quan hệ là được!!!). Việc mã xử lý các điểm vào sẽ rất rõ ràng ở giai đoạn này và sẽ phát hiện mã sử dụng có an toàn hay không cho điểm vào đó? Nếu như không an toàn thì đưa ra cách khắc phù triệt để và toàn diện. Có thể tóm tắt tất cả quá trình thực hiện như sau: 1) Xác định các thành phần liên quan đến ứng dụng 2) Xác định các điểm vào của ứng dụng 3) Tìm mối liên hệ giữa các điểm với mã nguồn của ứng dụng 4) Xây dựng sơ đồ các mối liên hệ giữa các điểm vào với mã nguồn của ứng dụng 5) Nhận biết điểm yếu và đưa ra cách khắc phục triệt để và toàn diện. II. Áp dụng Phần này seamoun sẽ giới thiệu một số công cụ tiêu biểu được sử dụng trong quá trình nhận biết lỗi bảo mật. 1) Application Code Scanning and Tracing tool (Blueinfy-AppCodeScan) có thể tải công cụ miễn phí tại đây ( http://blueinfy.com/AppCodeScan.zip)
Sau khi lựa chọn thư mục có chứa mã nguồn ứng dụng Web cần scan thì phải thực hiện lựa chọn rule (lựa chọn các kiểu cần áp dụng cho quá trình scan). Công cụ này có một tiện ích nhỏ giúp trace code (có thể trace biến hàm). Công cụ này chỉ thực hiện scan mã nguồn dựa trên các tập điểm yếu xây dựng sẵn để nhận biết các điểm có thể gây ra lỗi bảo mật trong ứng dụng Web. (Sẽ giới thiệu các công cụ khác trong phần tiếp theo ...)]]> /hvaonline/posts/list/36839.html#226359 /hvaonline/posts/list/36839.html#226359 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#226510 /hvaonline/posts/list/36839.html#226510 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn phần 2 2) RATS (Rough Auditing Tool for Security) Công cụ RATS cũng là một trong những công cụ thực hiện rà soát mã nguồn đối với một số ứng dụng được viết bằng các ngôn ngữ như C, C++, Perl, PHP, Python và Ruby do Secure Software Inc phát triển. Có download miễn phí công cụ tại https://www.fortify.com/ssa-elements/threat-intelligence/rats.html). Cộng cụ này cũng chỉ dựa trên tập các hàm mà có nguy cơ gây ra lỗi bảo mật đối với dụng và nó thực hiện scan với tốc độc đáng nể !!!. Sau khi thực hiện chạy công cụ thì công cụ sẽ đưa ra một danh sách các hàm và vị trí trong mã nguồn, giúp người kiểm tra có thể nhanh chóng tập trung ra soát lại các hàm mà RATS đưa ra, kiểm tra liệu khi sử dụng các hàm đó đã an toàn hay chưa ? Một số tùy chọn trong công cụ RATS Code:
usage: rats [options] [file]...

Options explained:
    -d <filename>, --db <filename>, --database <filename>
                    Specifies a vulnerability database to be loaded.  You may
                    have multiple -d options and each database specified will
                    be loaded.
    -h, --help      Displays a brief usage summary
    -i, --input     Causes a list of function calls that were used which
                    accept external input to be produced at the end of the
                    vulnerability report.
    -l <lang>, --language <lang>
         	    Force the specified language to be used regardless of 
                    filename extension. Currently valid language names are 
                    "c", "perl", "php", "python" and "ruby".
    -r, --references
	            Causes references to vulnerable function calls that are not
                    being used as calls themselves to be reported.
    -w <level>, --warning<level>
		    Sets the warning level.  Valid levels are 1, 2 or 3.   
                    Warning level 1 includes only default and high severity
                    Level 2 includes medium severity. Level 2 is the default 
                    warning level 3 includes low severity vulnerabilities.
    -x              Causes the default vulnerability databases (which are in 
                    the installation data directory, /usr/local/lib by default)
                    to not be loaded.
    -R, --no-recursion
		    Disable recursion into subdirectories.
    --xml	    Cause output to be in XML
    --html	    Cause output to be in HTML
    --follow-symlinks
		    Evaluate and follow symlinks.
3) Spike Php Security Audit Tool Công cụ spikephpSecAudit do SpikeSource phát triển và hoàn toàn miễn phí (có vẻ dự án bị dừng lại từ năm 2007, nhưng không sao, vẫn còn dùng tốt :D :D :D). Có thể download tại http://developer.spikesource.com/projects/phpsecaudit/) Ngoài ra nhóm này cũng có một số dự án hay liên quan, các bạn có thể vào trang web của nhóm này để tham khảo. Thực hiện kiểm tra mã nguồn rất đơn giản, chỉ cần download về giải nén và thực hiện: php.exe run.php <thư mục chứa mã nguồn hoặc tập tin cần kiểm tra> 4) Graudit Graudit cũng tương tự như công cụ RATS hỗ trợ rà soát nhiều mã nguồn. Tuy nhiên công cụ này chỉ chạy trên môi trường Linux. Các bạn có thể download tại đây http://www.justanotherhacker.com/projects/graudit.html) 5) RIPS Một công cụ tốt nhất về rà soát và đánh giá mã nguồn ứng dụng Web phát triển từ ngôn ngữ PHP. Thông tin chi tiết và download công cụ các bạn có thể truy cập tại đây http://sourceforge.net/projects/rips-scanner/
Sở dĩ nó là công cụ tốt nhất trong việc rà soát mà nguồn bởi vì công cụ RIPS không đơn giản là dựa vào tập nhận diện các hàm có thể xảy ra lỗi như là các công cụ đã giới thiệu RATS, GRAUDIT,AppCodeScan. Cách tiếp cận và kiểm tra mã nguồn dựa trên việc xác định các điểm vào của ứng dụng, từ đó thực hiện kiểm tra đối với những đối số đầu vào này trong mã nguồn ứng dụng (giống như cách tiếp cận mà seamoun đã giới thiệu ở trên) Ngoài những công cụ trên thì còn rất nhiều công cụ được phát triển nhằm bổ trợ cho việc rà soát mã nguồn. Toàn bộ những công cụ mà seamoun giới thiệu ở trên là miễn phí. Các công cụ thương mại thì seamoun thấy hình ảnh quảng cáo rất đẹp và có nhiều tính năng nhưng không biết nó thế nào ? :D :D :D. Công cụ chỉ vẫn là công cụ nó chỉ giúp cho người kiểm tra một phần nào đó, không thể có một công cụ nào đủ thông minh mà làm thay thế hoàn toàn con người được. Nếu có một công cụ như thế chắc anh em bị đuổi việc hết :D :D :D. Việc kiểm tra mã nguồn đòi hỏi người kiểm tra phải có cách quan sát tinh tế + độ “quái” khi cần thiết. ]]> /hvaonline/posts/list/36839.html#226573 /hvaonline/posts/list/36839.html#226573 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#254305 /hvaonline/posts/list/36839.html#254305 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn

chiro8x wrote:
Nhưng vấn đề thứ [3] là dữ liệu dị thường. Dữ liệu dị thường là một vấn đề rất đáng ngại, chúng ta không thể kiểm tra chương trình với toàn bộ các dữ liệu có thể phát sinh. Trong thực tế việc chương trình được kiếm tra ở design mode và chạy thử nghiệm rất ổn, nhưng lại gặp phải error runtime khi đi vào vận hành. Vấn đề là người lập trình không lường trước được sự dị thường của dữ liệu có thể phát sinh, hoặc "một người nào đó" có khả năng tìm ra dữ liệu dị thường để làm cho chương trình của ta crash, mà ngay cả khi chúng ta sử dụng tool và ở design mode chúng ta cũng không thể nào tìm ra nguyên do. Vấn đề mình muốn thảo luận cùng bạn là việc tạo thư viện các dữ liệu dị thường, và test ứng dụng của chúng ta trong sandbox (cái này phải nghĩ cách tạo). Theo bạn thì việc đó có làm cho chúng ta có được một sản phẩm tốt và ổn định hơn ?. 
Thử fuzz testing chưa?]]> /hvaonline/posts/list/36839.html#254325 /hvaonline/posts/list/36839.html#254325 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn

vulehcm wrote:
Thử fuzz testing chưa? 
Ý bạn đang đề cập tới vấn đề Fuzzy logic ?. Việc này hiện nay đang còn hạn chế. Các ứng dụng lập trình hướng trí tuệ hiện vẫn đang còn nằm ở các LAB và không biết lúc nào có thể ứng dụng cụ thể. Nếu bạn nói viết một chương trình sử dụng 1 mảng nhỏ của trí tuệ nhân tạo là fuzzy logic cho việc kiểm tra nghe cũng khả thi, nhưng vấn đề là fuzzy logic có nhiều điểm yếu kém của nó. Bạn phải tạo ra một môi trường và các luật để phân tích ứng dụng của bạn trong môi trường đó. Tôi tự hỏi việc đó có tốn kém hơn việc xây dựng sandbox và tạo ra thư viện chứa các dữ liệu dị thường không. Chúng ta chỉ quan tâm các hàm đầu vào X (p) và đầu ra Y (p). Việc khảo sát này thực tết và tiết kiệm thời gian hơn so với fuzz testing. P/S: Các ứng dụng chúng ta taọ ra có kích thước không nhỏ, quá trình tìm kiếm lỗi trong không gian tìm kiếm lớn cho độ phức tạp rất cao. Nên lượng tài nguyên chúng ta không đủ đáp ứng điều này sẽ biển một bài toán ở thời gian thực được giải trong một thời gian siêu thực :|. Cảm ơn việc mở rộng vấn đề của bạn.]]> /hvaonline/posts/list/36839.html#254333 /hvaonline/posts/list/36839.html#254333 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#254338 /hvaonline/posts/list/36839.html#254338 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn

vulehcm wrote:
Nên bỏ qua việc chuẩn bị ban đầu, việc chuẩn bị cho một giải pháp không phản ánh được hiệu quả của giải pháp đó mang lại. Có nhiều giải pháp việc chuẩn bị rất phức tạp nhưng đồng thời hiệu quả mang lại vô cùng cao, đó còn chưa nói đến việc chúng ta có thể sử dụng giải pháp đó nhiều lần mà không phải chuẩn bị (xây dựng) lại. Thử bỏ qua những điều tôi nói ở trên, bạn chiro8x phân tích lợi/nhược của hai giải pháp đã được thảo luận xem? 
Giờ tớ xin phân tích, nếu có thiếu sót mong được bạn chỉnh thêm. Dữ liệu đầu vào có những tính chất sau: + Khối lượng dữ liệu lớn. + Bao gồm nhiều object và module. + Số lượng biến, đối tượng được khởi tạo và phát sinh trong quá trình thực thi (runtime) lớn. + Dữ liệu đầu ra phân tán (đôi khi kết quá đầu ra của khâu này lại là đầu vào của khâu tiếp theo). Từ tính chất của dữ liệu tớ xin phân tích tiếp các ưu và nhược. 1. Sandbox: - Ưu: + Tận dụng các framework để tạo môi trường thực thi các đoạn mã. + Tiết kiệm thời gian vì chỉ quan tâm tới kết quả đầu vào và đầu ra. + Xữ lí dữ liệu lớn (bạn đã bao giờ thử nghiệm xem thời gian xử lý 1 script php hay aspx trong bao lâu chưa ?). + Đơn giản và không cần nhiều vốn đầu tư. - Nhược: + Độ tin cậy phụ thuộc vào thư viện chứa các dữ liệu dị thường. + Đễ đánh giá được độ tin cậy của sản phẩm, cần phải có những thuật toán được xây dựng nhằm tìm các tham số để đánh giá tính ổn định. + Trải qua nhiều quá trình lặp. 2. Fuzz testing: - Ưu : + Không trải qua nhiều quá trình lặp. + Kiểm tra ứng dụng theo một quá trình, không chỉ quan tâm tới kết quả đầu và cuối. - Nhược : + Thời gian tìm kiếm phụ thuộc vào không gian tìm kiếm. + Phải xây dựng môi trường có thể nhận biết syntax của các ứng dụng. + Xây dựng các luật phải chặt chẻ. + Có thể bị crash thường xuyên khi không gian tìm kiếm không hội tụ, và việc phân tích "hành vi" của ứng dụng đẩy nó vào vòng lặp. + Không thể xét sự dị thường dữ liệu. + Khá tốn kém và cần có vốn đầu tư lớn, khó nâng cấp. ]]> /hvaonline/posts/list/36839.html#254344 /hvaonline/posts/list/36839.html#254344 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#254803 /hvaonline/posts/list/36839.html#254803 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#259560 /hvaonline/posts/list/36839.html#259560 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#269519 /hvaonline/posts/list/36839.html#269519 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#269585 /hvaonline/posts/list/36839.html#269585 GMT Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn /hvaonline/posts/list/36839.html#269994 /hvaonline/posts/list/36839.html#269994 GMT