Free web security training from @PortSwigger
Joined April 2018
- Tweets1.8K
- Following36
- Followers146K
- Likes250
Seeing isAdmin in the API should instantly make your hacker-senses tingle.
Seeing it doesn't necessarily mean it's writable, but it's worth investigating.
Compare the object returned by GET with fields accepted by PATCH. An invalid-value test can reveal whether a hidden field is actually bound to the internal object.
See the Academy API-testing lesson 👇
portswigger.net/web-security…
Would the origin check accept app.example.attacker.test?
Substring, prefix, and suffix checks can accept an attacker-controlled origin that merely contains the expected domain.
Before event.data reaches a privileged action or DOM sink, validate event.origin against an exact, allowlisted origin.
Review the Academy lesson in your authorized app 👇
portswigger.net/web-security…
ALT A person wearing a hoodie sits at a table using a laptop displaying a fox logo, with a small backpack nearby. A diagram reads: "postMessage() CHECK" with steps including "received the message," "verify event.origin exactly," and "only then use event.data." Risky and safe practices are compared regarding origin validation. A box with a cat face and "User is admin!" text is on the floor. The image has Web Security Academy branding.
It's sometimes possible to take someone's private web app dashboard and trick it into being publicly cached.
The cache sees a static-looking request and stores the response, even though it shouldn't, and then you can view it as an attacker!
Learn more and try it yourself 👇
portswigger.net/web-security…
Before you trust the signature, open the JWT header and check 👇
🟧 alg tells the verifier which signing algorithm to try.
🟧 kid can select a verification key.
🟧 jku can tell a verifier where to fetch a key set.
Those fields are supplied by the token holder. The application should whitelist permitted algorithms and trusted key sources, then validate issuer, audience, and expiry.
Inspect JWTs in the free labs 👇
portswigger.net/web-security…
ALT A checklist titled "JWT verification checklist" on a dark blue background includes five items: "Algorithm is allowed," "Key source is trusted," "Issuer matches," "Audience matches," and "Token is still valid." Each item has a checkmark next to it. The bottom left shows the logo of Web Security Academy.
Pro tip for SSRF!
Blocking 127.0.0.1 does not necessarily account for every representation a parser may resolve as loopback. Depending on the parser, that can include case variations of localhost or shorthand forms such as 127.1.
Compare validation, normalization, DNS resolution, and the final request.
Explore the Academy SSRF labs 👇
portswigger.net/web-security…
What happens if this WebSocket handshake comes from another site?
Origin: https://evil.example
Send the handshake to Burp Repeater, change the Origin header, and reconnect.
If the server returns 101 Switching Protocols, inspect how the session is protected.
When the handshake relies only on a session cookie, contains no unpredictable token, and the victim’s browser sends the cookie cross-site, an attacker-controlled page could open the WebSocket as the victim.
The page then sends messages and reads responses in the victim’s session.
Follow the handshake in the free lab 👇
portswigger.net/web-security…
Can you change the response without changing the cache key?
In Repeater, add 👇
X-Forwarded-Host: cache-test.example
Then compare the response.
If the header changes the response but the cache does not include it in its key, it is an unkeyed input.
When that altered response is cached, later requests with the same cache key can receive it too.
Find the ignored input in the free labs 👇
portswigger.net/web-security…
Web Security Academy retweeted
You're in control with Burp AT.
The latest update makes sure Burp AT works your way:
📖 Custom skills for your methodology
🎯 /goal to keep it working until it gets there
💡 Requests, issues and docs as context
🚧 Reject, redirect or approve tool calls
#BurpAT
Web Security Academy retweeted
“Burp AT integrates seamlessly with Burp’s existing tooling and functionality, instead of being just another chat interface to an LLM.”
Burp AT vs Juice Shop, Safe Mode on, no hints: 3 unintended RCEs and a critical handlebars CVE (CVSS 9.2).
@ElliottSaysWhat, web app pentester at Leidos, shares what to feed it, how to steer it and what it cost.
brandon-t-elliott.github.io/…
Your password reset link:
https://attacker[.]com/reset?token=0a1b2c...
Why is the domain an attacker domain?!
That can happen when an application uses the request’s Host header to build the reset URL. This was actually a vulnerability in older versions of WordPress!
The email is genuine and the token is valid, but the domain is controlled by an attacker. If the victim opens the link, the token reaches the attacker’s server and can be used against the real reset endpoint.
Try exploiting this vulnerability yourself in our labs 👇
portswigger.net/web-security…
In Burp Repeater, try changing the file’s Content-Type to image/jpeg.
If a previously blocked upload is now accepted, the server may be trusting the multipart header instead of checking the file itself.
That header is supplied by the client. Validation also needs to consider the filename, extension, actual contents, storage location, and whether the server can execute the uploaded file.
Try it in the file upload labs 👇
portswigger.net/web-security…
Web Security Academy retweeted
How do you test how powerful an AI testing tool is?
@0xTib3rius built his own target: a bespoke vulnerable app, source code never published, with three known, tricky paths to RCE. Then he tried Burp AT.
Burp AT found a fourth within minutes.
#BurpAT
Sometimes applications are vulnerable to CSRF even when they use CSRF tokens!
This happens when the CSRF token isn't tied to the active session.
If an application accepts any token from a global pool, an attacker can create one from their own account and craft a CSRF payload to force a victim to perform requests on their account, using the attacker's CSRF token.
When testing for CSRF, you need to ask 2 questions:
- Does the application use CSRF tokens?
- Are the CSRF tokens tied to sessions?
Try it out in the free labs 👇
portswigger.net/web-security…
Web Security Academy retweeted
Have you ever felt like a model isn't actually trying to do what you asked? Did you just ask it wrong, or is there something else at play here? In "The model isn't cooperating", I take a little look. Link below 👇
You've found proto in input, here's what to do next 👇
To turn prototype pollution into impact, you need a source that adds a property, a gadget that inherits it, and a sink that uses it unsafely.
That is why a polluted object is not automatically a reportable exploit.
Use DOM Invader and the free labs to map the full chain 👇
portswigger.net/web-security…
Just like we have SQLi and blind SQLi, we also have XXE injection and blind XXE injection.
Sometimes, you find a XXE injection that does not reflect the entity value in the response, but there are still ways to exfiltrate data.
Learn here 👇
portswigger.net/web-security…
Sometimes, disabling the introspection is implemented as a regex against __schema keyword.
A simple newline character can be enough to create a discrepancy between the filter and the parser.
For GraphQL, whitespace is insignificant, but the regex will stop matching after that!
Try it out in the lab 👇
portswigger.net/web-security…
When finding a GraphQL instance, make sure to check out the following paths 👇
/graphql
/api
/api/graphql
/graphql/api
/graphql/graphql
Append /v1 if the first pass comes back empty.
GraphQL services answer non-GraphQL requests with "Query not present" or similar. It means that we can start querying from there.
Learn more here: portswigger.net/web-security…
In this lab walkthrough, we uploaded an SVG file with a nefarious XML payload inside to extract data.
Follow along here 👇
portswigger.net/web-security…
