Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận thâm nhập

Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	04/12/2010 23:05:31 (+0700) \| #1 \| 226359

seamoun
Advisor

Joined: 04/01/2002 14:05:10
Messages: 357
Offline

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 smilie

. 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 ...)

--vickigroup.com--

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	07/12/2010 08:04:25 (+0700) \| #2 \| 226510

WinDak
Researcher

Joined: 27/01/2002 11:15:00
Messages: 223
Offline

Cảm ơn anh seamon đã viết bài này. Hi vọng sẽ hiểu biết được thêm những công cụ mà industry đang sử dụng để QA code

-- w~ --

[Article] 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	07/12/2010 16:46:07 (+0700) \| #3 \| 226573

seamoun
Advisor

Joined: 04/01/2002 14:05:10
Messages: 357
Offline

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 smilie

). 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 ? smilie

. 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 smilie

. 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.

--vickigroup.com--

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	17/02/2012 23:36:07 (+0700) \| #4 \| 254305

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

Các chương trình cũng như biện pháp mà Seamoun đưa ra quả thực rất sát với nhu cầu thực tế, nhưng các chương trình rà soát lỗi gần như không giúp ích được quá nhiều. Sau đây là nhận định của em.

Nguyên nhân gây lỗi:
1. Lỗi từ người lập trình.
2. Lỗi từ framework (framework xung đột với các scripts/apps).
3. Dữ liệu dị thường (có thể do nhiều nguyên nhân vô tình hoặc cố ý).

Nguyên nhân [2] ta ít gặp, [1] và [3] phổ biến hơn. Lỗi từ người lập trình thì như seamoun nói có thể sử dụng các tool nói trên. 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 ?.

while(1){}

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	18/02/2012 07:04:31 (+0700) \| #5 \| 254325

vulehcm
Member

Joined: 21/11/2011 20:37:50
Messages: 46
Offline

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?

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	18/02/2012 08:27:12 (+0700) \| #6 \| 254333

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

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 smilie

. Cảm ơn việc mở rộng vấn đề của bạn.

while(1){}

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	18/02/2012 08:47:18 (+0700) \| #7 \| 254338

vulehcm
Member

Joined: 21/11/2011 20:37:50
Messages: 46
Offline

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?

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	18/02/2012 09:23:48 (+0700) \| #8 \| 254344

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

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.

while(1){}

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	21/02/2012 20:30:24 (+0700) \| #9 \| 254803

vulehcm
Member

Joined: 21/11/2011 20:37:50
Messages: 46
Offline

Bạn chiro8x đã chỉ ra được rất nhiều điểm đáng thảo luận. Riêng vì tớ kiến thức hạn hẹp nên không đào sâu tiếp được, có bạn nào hứng thú với topic này thì đào sâu vào những điểm bạn chiro8x nêu ra để chúng ta cùng mở rộng thảo luận smilie

Cám ơn bạn chiro8x đã mở rộng chủ đề.

Best regards,

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	22/03/2012 09:01:16 (+0700) \| #10 \| 259560

hoalucky
Member

Joined: 28/06/2007 23:22:57
Messages: 46
Offline

Bài viết này hay. ủng hộ bác.

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	24/08/2012 04:44:37 (+0700) \| #11 \| 268688

hieuvan50
Member

Joined: 11/03/2012 03:37:01
Messages: 1
Offline

This post is set hidden by a moderator because it may be violating forum's guideline or it needs modification before setting visible to members.

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	27/08/2012 09:32:11 (+0700) \| #12 \| 268801

soever1990
Member

Joined: 16/05/2012 02:54:26
Messages: 1
Offline

This post is set hidden by a moderator because it may be violating forum's guideline or it needs modification before setting visible to members.

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	20/09/2012 04:25:31 (+0700) \| #13 \| 269519

totden
Member

Joined: 07/10/2008 02:37:47
Messages: 17
Offline

Bạn chiro8x có thể cho mình hỏi tí:
Mình ko hiểu cụ thể cái sandbox của chiro8x là làm cái gì nhỉ? Theo mình hiểu sandbox thì nó chỉ cho phép các ứng dụng chạy trong đó không tác động ra ngoài.
Như vậy nó cần 1 ứng dụng nữa để đưa đầu vào và đầu ra cho ứng dụng đc test nữa đúng ko?

Tập dữ liệu bất thường đó cũng là đc xây dựng cho từng ứng dụng khác nhau nó cũng sẽ khác nhau đúng ko?

Nghe như bạn mô tả thì có vẻ RIPS nó giống với cái mà bạn nói, nhưng mình ko thấy có gì là sandbox ở trong đó cả.

Thêm 1 câu nữa: bạn có mô hình nào cụ thể để mình hiểu về QA dựa theo sandbox này đc ko?

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	21/09/2012 01:56:04 (+0700) \| #14 \| 269585

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

1. Mình ko hiểu cụ thể cái sandbox của chiro8x là làm cái gì nhỉ?

-> Trong quá trình tìm hiểu mình được biết, sandbox được phát triển trên công nghệ oả hoá, tuy nhiên việc ảo hoá này không giống với virtual machine, nó tạo ra một vùng ảo trên máy thực để thực thi chương trình chưa được chứng thực. Có lẽ mình dùng từ sandbox ở đây là chưa sát. Như bạn thấy việc thực thi các script như PHP/ASP/JS thường thông qua một framework, mình chỉ cổ tạo ra một vùng đệm giữa framework đó và script, mục đích truyền tham số và nhận các tác động trở lại.

2. Theo mình hiểu sandbox thì nó chỉ cho phép các ứng dụng chạy trong đó không tác động ra ngoài.

-> Bạn sử dụng sandbox chủ yếu để sử dụng các ứng dụng (chưa được bạn hoặc một tổ chức uy tín nào đó chứng thực) mục đích là bạn muốn sử dụng các khả năng của ứng dụng đó. Vậy làm sao bạn có thể sử dụng khi không tương tác với nó (thông qua GUI, command line, file I/O stream ?).

3.Như vậy nó cần 1 ứng dụng nữa để đưa đầu vào và đầu ra cho ứng dụng đc test nữa đúng ko?
-> Đúng

4. Tập dữ liệu bất thường đó cũng là đc xây dựng cho từng ứng dụng khác nhau nó cũng sẽ khác nhau đúng ko?
-> Có những dữ liệu bất thường chung có thể dẫn tới trạng thái không ổn định của một chương trình, bạn đọc về bài viết tràn bộ đệm trong box RCE biết thêm, tớ không rành mãng đó.

Ex. Mình nhớ lúc trước (2002) có một chương trình NUKE chuyên tấn công một số loại modem dail-up, nó gửi NULL bytes và 0x41 (A) để thực hiện DoS, mãi sau này một số chương trình UDP Flood vẫn sử dụng dữ liệu đó.

5. Nghe như bạn mô tả thì có vẻ RIPS nó giống với cái mà bạn nói, nhưng mình ko thấy có gì là sandbox ở trong đó cả.
-> RIPS là sản phẩm cuối rối chứ RIPS không phải là tên mà công nghệ người ta sử dụng. Có lẽ mình sẽ tìm từ nào đó thích hợp hơn, hoặc bạn tìm hiểu về định nghĩa của sandbox xem nó có phù hợp không.

6. Thêm 1 câu nữa: bạn có mô hình nào cụ thể để mình hiểu về QA dựa theo sandbox này đc ko?
-> Tuỳ theo câu hỏi của bạn hay không, tuỳ theo khả năng của mình có thể trả lời nỗi nó không. Nhưng bạn luôn được chào đón.

while(1){}

[Article] Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn	09/10/2012 06:42:22 (+0700) \| #15 \| 269994

phuonggm
Member

Joined: 06/10/2012 01:43:29
Messages: 1
Location: Hà Nội
Offline

Mình mới vào nên không rõ lắm
Mình không thấy nút Thanks ^^~
Thanks chủ top vì bài viết rất hay nhé. Nhất là với mình smilie

Phương GM

Go to:

Users currently in here
1 Anonymous