Những lưu ý khi kiểm thử một website

Đặc điểm của ứng dụng web

Chỉ cài đặt trên máy chủ Cần có hệ thống mạng nội bộ(LAN)Các máy trạm làm việc chỉ cần một trình duyệt web Dữ liệu tập trung trên server Quản lý và bảo mật tốt hơn

Phân biệt web app và win app 

khi thực hiện kiểm thử một ứng dụng web chú ý các đầu mục dưới đây:

1. Interface testing

A. Nội dung hoạt động :

• Thông tin thể hiện như menu, kích thước, vị trí, màu sắc, font chữ thể hiện trên form
• Kiểm tra các điều khiển: Textbox, option (radio button), check boxes, command button, combo boxes, list boxes, Label, Dialog, Icon/Tooltip, Phím nóng/ tắt, các phím Tab/ Shift tab/ enter/ ESC, Focus con trỏ, Thông báo, Menu điều khiển, dấu hiệu của trường bắt buộc
• Giá trị mặc định

B.Phương pháp thực hiện:

Xác định được số Form cần test (dựa theo tài liệu thiết kế giao diện nếu có)

Kiểm tra lần lượt các điều khiển trên cùng 1 form theo trật tự từ:

• Trên xuống dưới
• Từ trái sang phải
• Từ mỗi điều khiển độc lập đến logic giữa các điều khiển

Kiểm tra các nội dung trên mỗi Form như sau:

• Màu sắc hài hoà hợp lý, vị trí các điều khiển đặt theo yêu cầu khách hàng (nếu có trong yêu cầu).
• Các nút hiển thị ở các Form tương tự nhau phải giống nhau trừ khi có yêu cầu riêng.
• Các tên thuộc tính dạng text tương ứng với các điều khiển trên Form đều phải đúng chính tả không dùng tiếng anh.
• Kiểm tra giao diện các Form trên các trình duyệt khác nhau đảm bảo phải như nhau.

C. Những lỗi thường gặp:

1. Các Form giao diện không nhất quán về màu sắc, tên nút, các nút không cùng kích cỡ.
2. Các câu thông báo thường sai chính tả hoặc là tiếng anh hoặc tiếng việt không dấu.
3. Lỗi chính tả (tên Form, tên nút lệnh, tên trường thuộc tính...)
4. Thiếu ký tự * bên cạnh trường bắt buộc
5. Câu thông báo không chính xác với thao tác đã thực hiện
6. Sai trật tự Tab
7. Khi một nút lệnh không được sử dụng trong 1 số thời điểm nó không được chuyển sang màu xám mờ
8. Tên các nút lựa chọn mang tính kỹ thuật, không dễ hiểu với người dùng hệ thống.
9. Không Focus con trỏ chuột tới thuộc tính đầu tiên của form.

Phân biệt UI và UX (User interface and User experiences)

Basic functionality testing

A. Nội dung cần test

• Việc xử lý các thao tác (action): Add,Update,Delete,Data type, Select , View, Search, Import/Export, Share/Send data
• Valid data: Việc xử lý các chức năng với việc nhập các bộ dữ liệu hợp lệ
• Invalid data:Việc xử lý các chức năng với việc nhập các bộ dữ liệu không hợp lệ
• Flow: Việc xử lý mối liên hệ giữa các chức năng theo luồng nghiệp vụ.

B. Phương pháp thực hiện

Để test function, Kiểm thử viên sẽ áp dụng tất các kỹ thuật test để phân tích ra các trường hợp hợp lệ và các trường hợp không hợp lệ, các luồng nghiệp vụ đúng ...

• Khi test valid data và invalid data thì áp dụng các kỹ thuật test phân tích giá trị biên, phân vùng tương đương để tạo dữ liệu.
  • Ví dụ: Đối với trường nhận giá trị text thì sẽ có thể có những case sau:
    • characters: " the material is publish for all person "
    • number: "123"
    • special character: "!@#$%"
    • html tags:<script> the material is publish for all person </script>
    • html tags: <script>alert("xss error") </script>
    • html tags: <script> window.open("http://learningtesting.net") </script>
• Khi test việc xử lý theo các action thì cần chú ý : với mỗi thao tác của người dùng đều làm cho hệ thống biến đổi sang một trạng thái khác.
• Khi test flow: kiểm thử viên phải hiểu và nắm được về luồng nghiệp vụ của mỗi phần mềm.

Link testing

A. Nội dung kiểm thử

• Kiểm tra các links liên kết ngoài trang web
• Kiểm tra tất cả các links nội bộ
• Kiểm tra các links tới các vị trí trong cùng trang
• Kiểm tra các links sử dụng để gửi mail tới admin hoặc người dùng khác từ trang web
• Kiểm tra xem có trang trống nào không
• Kiểm tra các links bể trong tất cả các links nói trên

B. Phương thức thực hiện Ví dụ Test tất cả link nội bộ trong trang facebooks.com :)))

• Vào công cụ hỗ trợ Link checker: http://validator.w3.org/
• Nhập địa chỉ trang web:
• Kết quả trả về về những trang bị broken

Compatibility testing

A. Nội dung kiểm thử

• Kiểm thử sự tương thích với trình duyệt
• Kiểm thử sự tương thích với hệ điều hành
• Kiểm thử sự tương tích với thiết bị di động
• Kiểm thử sự tương thích với tùy chọn các thiết bị ngoại vi ( máy in …)

B. Phương pháp thực hiện

Khi test một web thì cần phải có các yêu cầu:

• Chạy trên hệ điều hành: window… back 2 trở lên
• Chạy các trình duyệt : firefox, chrome, IE,
• Chạy trên các trình duyệt của các thiết bị di động có hệ điều hành là android hoặc ios.
• Có thể kết nối với máy in để in bài

=> Khi kiểm thử phải thực hiện kiểm thử tính tương thích của phần mềm với tất cả các yêu cầu trên.

Usability testing

A. Nội dung kiểm thử:

• Kiểm thử cho chuyển hướng
• Kiểm thử tính khả dụng
• Kiểm thử nội dung
• Các thông tin hỗ trợ người dùng

B. Phương pháp thực hiện:

Trên các grid list ở hình phải sort được theo các cột thông tin: <chen hinh > Thời gian Order mới nhất

• Số lượng người tham dự từ lớn xuống bé
• Slượng vé từ thấp lên cao
• Trạng thái theo vần alpha Nen Đối với tính khả dụng này, có thểm làm theo yêu cầu cụ thể của khách hàng với từng tiêu chí ứng với nghiệp vụ.

Security testing

A. Nội dung kiểm thử

• Kiểm tra lỗi SQL Injection:
• Kiểm tra lỗi XSS
• Kiểm tra lỗ hổng CSRF
• Kiểm tra lỗi Path Traversal
• Kiểm tra lỗi mã hóa dữ liệu
• Kiểm tra lỗi xác thực/phân quyền
• Kiểm tra lỗi User enumeration
• Kiểm tra lỗi Session fixation
• Kiểm tra lỗ hổng cho phép dò đoán mật khẩu, thu thập danh sách, thông tin người dùng: Các ứng dụng không có cơ chế bảo vệ sử dụng captcha, lock account khi đăng nhập sai quá số lần quy định đều có khả năng bị mắc lỗi này.

B. Cách thức thực hiện

• Ví dụ 1: Kiểm tra lỗi sql injection Nhập vào form đăng nhập chuỗi ký tự đặc biệt: test' or '1'='1. Hệ thống đăng nhập thành công => bị lỗi sql injection
• Ví dụ 2: Kiểm tra lỗi xss:
  • Nhập vào chuỗi kí tự <script>alert(“ XSS”)</script> vào những nơi có thể nhập được dữ liệu
  • Sau đó, kích nút Lưu

=> Nếu ứng dụng lưu lại và cho phép thực thi script thì trên trình duyệt sẽ xổ ra cửa sổ có dòng chữ “ XSS”, khi đó ứng dụng bị mắc lỗi XSS.

Tìm hiểu thêm lỗi và cách tấn công website bằng XSS

• Ví dụ 3: Kiểm tra lỗi xác thực/phân quyền: Sử dụng 2 user, 1 user có quyền thấp và 1 user có quyền cao hơn. Khi sử dụng user có quyền cao truy cập vào các chức năng dành riêng ta ghi lại các đường dẫn trên URL, sau đó đăng nhập vào bằng user quyền thấp và thử truy cập vào link đó. Nếu ứng dụng cho phép user truy cập thì cơ chế xác thực phân quyền của ứng dụng không có tác dụng.
• Ví dụ 4: kiểm tra lỗi User enumeration : Đăng nhập vào ứng dụng (cố tình nhập sai user hoặc password sai). Nếu ứng dụng trả về câu thông báo cụ thể là “sai mật khẩu” hoặc “sai user” thì ứng dụng mắc lỗi. Còn nếu trả về câu thông báo chung ví dụ “Username hoặc password không đúng.” thì không bắt lỗi.
• Ví dụ 5: Kiểm tra lỗi lỗ hổng cho phép dò đoán mật khẩu, thu thập danh sách, thông tin người dùng: Các ứng dụng không có cơ chế bảo vệ sử dụng captcha, lock account khi đăng nhập sai quá số lần quy định đều có khả năng bị mắc lỗi này

Performance testing/Load test/ Stress test

A. Performance Testing:

Công cụ kiểm thử: jmeter tool

• Kiểm tra hiệu quả thực thi của ứng dụng như Thời gian phản hồi và Tốc độ thực hiện của nó
• Mục đích: giúp phát hiện ra những vẫn đề thiếu xót về tài nguyên của server – side như:
  • Ảnh hưởng của băng thông
  • Khả năng của database
  • Yêu cầu phần cứng/phần mềm

B. Load testing

• Kiểm tra hệ thống thực thi trong điều kiện có nhiều người dùng cùng truy xuất đồng thời dưới nhiều điều kiện khác nhau:
• Mục đích:
  • Nhiều người cùng truy cập
  • Nhiều giao dịch thực hiện cùng lúc
  • Xử lý file dung lượng lớn
  • Xử lý cùng lúc nhiều file …

C. Stress Test

• Kiểm tra dựa trên việc tăng liên tục mức độ chịu tải cho đến khi hệ thống ngưng hoạt động
• Mục đích: xác định mức tới hạn của hệ thống có thể đáp ứng

Đối với các loại kiểm thử này, người dùng thông thường sử dụng một số loại tool test tự động để thực hiện nó như jmeter, quick test pro, …

Regression test

• Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc thay đổi code. Đặc biệt, nó tìm kiếm theo cách hồi qui (đệ qui) hoặc kiểm tra các bug cũ có bị lại hay không. Hồi qui như vậy xảy bất cứ khi nào mà chức năng phần mềm trước đây làm việc đúng đã ngưng làm việc theo mong đợi.
• Hướng dẫn thực hiện:
  • Với các dự án nhỏ, kiểm thử hồi quy được thực hiện thủ công.
  • Với các dự án vừa và lớn, có khoảng thời gian xây dựng, phát triển và duy trì lâu dài thì người ta hướng tới việc viết các kịch bản tự động test. Kiểm thử viên có thể sử dụng các tool như selenium để viết các script tự động này.

Continue Reading →

WHITE BOX TESTING

Khái niệm: Còn được gọi là clear box testing, glass box testing, transparent box testing, or structural testing,  thường thiết kế các trường hợp kiểm thử dựa vào cấu trúc bên trong của phần mềm.

Đặc điểm: Phụ thuộc vào các cài đặt hiện tại của hệ thống và của phần mềm, nếu có sự thay đổi thì các bài test cũng cần thay đổi theo. Được ứng dụng trong các kiểm tra ở cấp độ mô đun(điển hình), tích hợp (có khả năng) và hệ thống của quá trình test phần mềm.

Các kỹ thuật:

Kiểm thử luồng, lộ trình ( Deriving Test Cases)

+ Lộ trình cơ sở (Basis path Testing)

Luồng điều khiển / Phạm vi

(Control-flow / Coverage Testing)

+ Phương thức – Method Coverage

+ Câu lệnh – Statement Coverge

+ Nhánh –  Branch Coverge

+ Điều kiện – Condition Converage

Kiểm thử luồng dữ liệu ( Data Flow Test )

Trường hợp hỏng ‘rác’ – Failure ‘Dirty’ Case Test

Flow Groaps Revisited

Basis Path Testing ( Kiểm thử lộ trình cơ sở)

Equivalence Partitioning / Boundary Value( Phân vùng tương đương và Giá trị biên )

Kiểm tra lộ trình cơ sở :

+ Là kĩ thuật kiểm thử mà phần mềm được chia thành các lộ trình

+ Đảm bảo các lộ trình độc lập qua một mô đun mã sẽ được kiểm thử đầy đủ

Một số khái niệm:

Đồ hình lộ trình : Bao gồm các hình, mũi tên (cạnh), chỉ số, mô tả khác

Độ phức tạp chu trình ( Cyclomatic Complexity ) : Được tìm ra bởi chu trình McCabe, chỉ ra độ phức tạp lôgic của một chương trình.

Cách tạo kiểm thử:

Sử dụng một đoạn code hoặc thiết kế làm cơ sở để xây dựng lên đồ hình luồng.

Đưa ra các chu trình lộ trình từ đồ hình vừa có được.

Quyết định một lộ trình độc lập tuyến tính

Kiểm tra tất các chu trình đã tạo.

v Luồng điều khiển / Gom  (Control-flow / Coverage Testing)

Là cách tạo ra các bộ giá trị kiểm thử để có thể xem được 100% các trường hợp có thể xảy ra với các thành phần của một chương trình bao gồm :

+ Các phương thức ( Method )

+ Các câu lệnh (Statement )

+ Các nhánh (branch)

+ Các điều kiện

Ví dụ: Kiểm tra phương thức bằng các bộ giá trị của hàm foo sau :

Bộ giá trị được chọn là  foo(0,0,0,0,0)

v Luồng điều khiển / Phạm vi (Control-flow / Coverage Testing)

Với nhánh (branch )

IF ( a equals b AND c less than d ) THEN
statement 1
ELSE
statement 2
END IF

Chọn bộ giá trị a b c d sao cho có thể kiểm tra hết các nhánh rẽ .

Ví dụ : (a,b,c,d) = (1, 1, 2, 6) & (1,2,3,3)

v Kiểm thử luồng dữ liệu ( Data Flow Test )

Kiểm tra sự khởi tạo, biến đổi và huỷ của các các luồng  dữ liệu.

Thường  được phân tích qua đồ hình và đặt ra các bộ giá trị thử và giá trị trả về  mong muốn  dựa vào đồ hình đó.

Một số trạng thái của biến dữ liệu trong quá trình biến đối

Ví dụ: Hoá đơn thanh toán cho việc sử dụng điện -> Xét sự biến đổi luồng dữ liệu của hóa đơn

v Trường hợp hỏng ‘rác’ (Failure ‘Dirty’ Case Test)

Là trường hợp kiểm thử các trường hợp mà người lập trình cần đứng ở vị trí người dùng để nhập giá trị

Cụ thể là người dùng có thể nhập số thay cho chữ, hoặc không nhập gì, tạo ra lỗi phép toán (divided by Zero )…

Cách kiểm thử:

Tạo ra tất cả các trường hợp test mà người dùng thường mắc lỗi ( dựa vào kinh nghiệm thực tế )

Kiểm tra các lỗi toán học, số học, phạm vi biến, kiểu biến ….

Continue Reading →

Tìm hiểu cơ chế SQL injection tester nên biết

Những lỗi sơ hở trong quá trình build ứng dụng web/ phần mềm, hacker sử dụng lỗi này để lạm dụng các câu truy vấn sql bất hợp pháp để tấn công vào web ứng dụng của chúng ta.

Sẽ hơi mơ hồ nếu như không đi từ lý thuyết thì rất khó hiểu bởi vậy ta đi từ lý thuyết kèm ví dụ minh họa nha.

Sql injection: Bạn học môn hệ quản trị cơ sở dữ liệu sql server, oracle, DB2, mongo,... biết được cú pháp, thao tác select , from, having, group by, where, inner join... thao tác các bảng dữ liệu vớinhau

Sql injection là kỹ thuật cho phép hacker lợi dụng chỗ sơ hở trong việc kiểm tra dữ liệu đầu vào ở ứng dụng web và các notification của hệ quản trị CSDL trả về để inject và thi hành các câu lệnh SQL bất hợp pháp bằng các thao tác delete, insert, update,...

chúng ta hãy để ý đến những lỗi cơ bản thường gặp dưới đây:

1. Không kiểm tra kí tự thoát truy vấn:

Sql injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu vào trong câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện 1 số truy vấn không mong muốn với CSDL:

statement = "SELECT * FROM users

WHERE name = '" + userName+ "' ;"

>>> Câu lệnh trên truy vấn thuôc tính name từ bảng users. Tuy nhiên, nếu biến "userName" được nhập chính xác theo 1 cách nào đó thì người dùng ác ý có thể nhập vào giá trị của biến userName như sau:

" SELECT * FROM users

WHERE name = 'a' OR 't' = 't';"

Đoạn mã trên được sử dụng trong 1 thủ tục xác thực thì VD trên có thể được sử dụng để bắt buộc lựa chọn 1 tên người dùng hợp lệ bới ' t' = 't' luôn đúng. Trong khi hầu hết các SQL server cho phép thực hiện nhiều truy vấn cùng lúc chỉ với 1 lần gọi, nhưng 1 số SQL API mysql_query của PHP lại không cho phép làm điều đó vì lý do bảo mật. Điều này chỉ ngăn cản tin tặc tấn công bằng những câu lệnh riêng rẽ mà không ngăn cản tin tặc tấn công bằng việc thay đổi cú pháp truy vấn.

Ở ví dụ trên cho thấy các giá trị của biến userName sẽ gây ra việc xóa thông tin người dùng từ bảng users cũng tương tự từ việc xóa tất cả dữ liệu từ bảng dữ liệu ( bản chất là tiết lộ thông tin người dùng) . Minh hoạ cụ thể bằng câu truy vấn dưới đây để hiểu rõ được bản chất hơn:

" DROP TABLE users;

 SELECT * FROM data

 WHERE 't' = 't'

Tổng hợp lại toàn bộ câu truy vấn như sau:

DROP TABLE users

SELECT * FROM data 

WHERE 't' = 't';

Như vậy là tin tặc lợi dụng lỗi sơ hở cú pháp truy vấn trên để chỉ việc thay đổi thêm bớt vài lệnh truy vần truyền vào là có thể xâm nhập được hệ thống của chúng ta 1 cách dễ dàng.

Điều thứ 2 liên quan tới SQL injection đó là Xử lý không đúng kiểu.

Do coder định nghĩa dữ liệu đầu vào không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ liệu đầu vào (ví dụ kiểm tra dữ liệu nhập vào từ user là kiểu số hay chuỗi

state = "SELECT * FROM data WHERE id = "+ a_variable +" ;"

Lệnh state trên cho chúng ta biết rằng cho người dùng nhập vào id dạng số nhưng lại không kiểm tra kiểu nhập vào nên người dùng thay vì nhập số mà nhập vào 1 chuỗi string.

Điều thứ 3 xảy ra là lỗi bảo mật bên trong máy chủ CSDL

Đôi khi lỗ hổng bảo mật nằm ngay chính máy chủ CSDL, VD hàm mysql_real_escape_string() 

hacker có thể thực hiện cuộc tấn công SQL injection thành công dựa trên những ký tự unicode không thông thường ,

lấy 1 sồ VD minh hoạ

$user ="<div> user </div>

$password = "<div> password</div>

 $query = sprintf( "SELECT * FROM users 

WHERE username ='%s' AND password = '%s'")

mysql_real_escape_string($username)

mysql_real_escape_string($password)

echo $query;

 Kết quả in ra sẽ là:

SELECT * FROM users WHERE user = ' ' AND password = ' '

Tiếp đến 1 trường hợp nữa tại form đăng nhập, người dùng nhập tên đăng nhập mà không cần đúng mật khẩu

<?php

$query = "SELECT * FROM users

WHERE username = '{$_POST['username']}' AND password = '{$_POST['password']}'";

mysql_query($query);

$_POST['username'] = ' your's name';

$_POST['password'] = " OR "=";

echo $query;

?>

Câu  lệnh truyền lên server sẽ là:

SELECT * FROM users WHERE username = 'yours name' AND password = " OR "=" 

4. Điều thứ 4 xảy ra là Blind SQL injection

Lỗi SQL injection dạng Blind SQL injection xảy ra ngay trong ứng dụng web, hậu quả của chúng  không hiển thị trực quan cho những kẻ tấn công. Nó có thể gây ra sự sai khác khi hiển thị  nội dung của 1 trang chứa lỗi bảo mật này. Hậu quả của sự tấn công SQL injection dạng Blind SQL injection này khiến cho coder phải mất nhiều time để phục hồi chính xác từng bit dữ liệu. Những kẻ tấn công còn sử dụng 1 số tool tìm dò lỗi và tấn công với những thông tin đã thiết lập sẵn

 Còn rất nhiều các dạng tấn công khác xảy ra khi mà hacker sử dụng kỹ thuật SQL injection và lỗi sơ hở trong các câu truy vấn để đột nhập lấy cắp dữ liệu

Update thêm các dạng tấn công thường gặp với ứng dụng web

1.    Dạng tấn công vượt qua kiểm tra lúc đăng nhập

Với dạng tấn công này, tin tặc có thể dễ dàng vượt qua các trang đăng nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên cơ sở dữ liệu của ứng dụng web. Thông thường để cho phép người dùng truy cập vào các trang web được bảo mật, hệ thống thường xây dựng trang đăng nhập để yêu cầu người dùng nhập thông tin về tên đăng nhập và mật khẩu. Sau khi người dùng nhập thông tin vào, hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết định cho phép hay từ chối thực hiện tiếp. Ví dụ, trong trường hợp sử dụng ASP, người ta có thể dùng 2 trang: 1 trang HTML để hiển thị Form nhập liệu và 1 trang ASP để xử lý thông tin nhập vào từ phía người dùng như sau:

- Trang nhập liệu: login.htm 

<form action="ExecLogin.asp" method="post"> 

  Username:  <input type="text" name="fUSRNAME"><br /> 

  Password:  <input type="password" name="fPASSWORD"><br /> 

  <input type="submit"> 

</form>

- Trang xử lý nhập liệu: execlogin.asp

<%

Dim vUsrName, vPassword, objRS, strSQL

vUsrName = Request.Form("fUSRNAME")

vPassword = Request.Form("fPASSWORD")

strSQL = "SELECT * FROM T_USERS " & _

"WHERE USR_NAME=' " & vUsrName & _

" ' and USR_PASSWORD=' " & vPassword & " ' "

Set objRS = Server.CreateObject("ADODB.Recordset")

objRS.Open strSQL, "DSN=..."

If (objRS.EOF) Then

Response.Write "Invalid login."

Else

Response.Write "You are logged in as " & objRS("USR_NAME")

End If

Set objRS = Nothing %>

Chỗ sơ hở trong đoạn mã xử lý nhập liệu trên nằm ở chỗ dữ liệu nhập vào từ người dùng được dùng để xây dựng trực tiếp câu lệnh SQL. Chính điều này cho phép tin tặc có thể điều khiển câu truy vấn sẽ được thực hiện. Ví dụ, nếu người dùng nhập chuỗi trong ngoặc sau vào trong cả 2 ô nhập liệu username/password của trang login.htm là:('OR='). Lúc này, câu truy vấn sẽ được gọi thực hiện là:

SELECT * FROM T_USERS WHERE USR_NAME =''OR''='' AND USR_PASSWORD= ''OR''=''

Câu truy vấn này là hợp lệ và sẽ trả về tất cả các bản ghi của T_USERS và đoạn mã tiếp theo xử lí người dùng đăng nhập bất hợp pháp này như là người dùng đăng nhập hợp lệ.

2.    Dạng tấn công sử dụng câu lệnh SELECT

Dạng tấn công này phức tạp hơn

 Để thực hiện được kiểu tấn công này, kẻ tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo lỗi từ hệ thống để dò tìm các điểm yếu khởi đầu cho việc tấn công. Ví dụ, trong các trang tìm kiếm. Các trang này cho phép người dùng nhập vào các thông tin tìm kiếm như Họ, Tên, … Đoạn mã thường gặp là:

    <%

    Dim vAuthorName, objRS, strSQL

    vAuthorName = Request("fAUTHOR_NAME")

    strSQL = "SELECT * FROM T_AUTHORS WHERE AUTHOR_NAME =' " & _ vAuthorName & " ' "

    Set objRS = Server.CreateObject("ADODB.Recordset")

    objRS.Open strSQL, "DSN=..."

    …

    Set objRS = Nothing %> 

Tương tự như trên, tin tặc có thể lợi dụng sơ hở trong câu truy vấn SQL để nhập vào trường tên tác giả bằng chuỗi giá trị:

' UNION SELECT ALL SELECT OtherField FROM OtherTable WHERE ' '=' (*)

Lúc này, ngoài câu truy vấn đầu không thành công, chương trình sẽ thực hiện thêm lệnh tiếp theo sau từ khóa UNION nữa. Giả sử đoạn mã nhập vào là:

' DROP TABLE T_AUTHORS --

Câu truy vấn sẽ thực hiện việc xóa bảng.

3.    Dạng tấn công sử dụng câu lệnh INSERT

Ví dụ điển hình nhất ở thao tác đăng ký thông tin người dùng, sau khi đăng ký thành công, người dùng có thể xem thông tin của mình. Ngay lúc này SQL injection có thể được dùng khi hệ thống không kiểm tra tính hợp lệ của thông tin nhập vào. Ví dụ, một câu lệnh INSERT có thể có cú pháp dạng:

    INSERT INTO TableName VALUES('Value One', 'Value Two', 'Value Three')

Nếu đoạn mã xây dựng câu lệnh SQL có dạng:

<%

    strSQL = "INSERT INTO TableName VALUES(' " & strValueOne & " ', ' " _ & strValueTwo & " ', ' " & strValueThree & " ') "

    Set objRS = Server.CreateObject("ADODB.Recordset")

    objRS.Open strSQL, "DSN=..."

    …

    Set objRS = Nothing %> 

Thì chắc chắn sẽ bị lỗi SQLi, bởi vì nếu ta nhập vào trường thứ nhất ví dụ như:

    ' + (SELECT TOP 1 FieldName FROM TableName) + '

Lúc này câu truy vấn sẽ là:

    INSERT INTO TableName VALUES(' ' + (SELECT TOP 1 FieldName FROM TableName) + ' ', 'abc', 'def')

Khi đó, lúc thực hiện lệnh xem thông tin, xem như bạn đã yêu cầu thực hiện thêm một lệnh nữa đó là:

 SELECT TOP 1 FieldName FROM TableName 

Trên đây là cơ bản về kỹ thuật SQL injection, là tester chúng ta ít nhiều nên biết về kỹ thuật này để trau dồi kinh nghiệm test cho mình J

Bài viết trên tham khảo tại wiki và 1 số trang công nghệ khác. Bạn đọc thấy thiếu sót chỗ nào phản hồi góp ý với mình nha. Thanks for reading!

Câu hỏi thường gặp khi phỏng vấn tester

Continue Reading →

Tổng quan về kiểm thử

Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử.^[1] Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khaiphần mềm.

Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm cáclỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm:

• Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
• Thực hiện công việc đúng như kỳ vọng.
• Có thể triển khai được với những đặc tính tương tự.
• Và đáp ứng được mọi nhu cầu của các bên liên quan.

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì các nỗ lực kiểm thử được tiến hành

Continue Reading →