top of page

Storming The Castle Series #2

  • Writer: Last Tower
    Last Tower
  • Feb 27, 2024
  • 2 min read



Ep. #2 Evading the Web App Watchtower


Chaining XSS (Cross-Site-Scripting) and CSRF (Cross-Site-Request-Forgery) with WAF (Web Application Firewall) Bypass Techniques for Account Takeover


Our team had been working on testing a PHP web application, putting in days of effort. Amidst the routine traffic analysis in BurpSuite, a peculiar endpoint caught our eye at:


onlinestore/osx/index/keywords


This particular page offered users the ability to customize their experience by altering their preferred region and specifying keywords for items on their home store page. The team identified an unusual discovery and realized the potential for HTML injection in one of the fields.


For instance:


"><h2>ltswashere</h2>


Successfully navigating this, the team attempted an XSS payload commonly known to be effective:


"><img+src=1+onerror=alert(1)>


Yet, our enthusiasm was met with a stumbling block—a 403 forbidden server error message from the Akamai Web Application Firewall (WAF) prevented the alert from triggering. Undeterred, we tirelessly attempted various Akamai WAF bypass payloads as found here: https://lnkd.in/gU8Ud-WA but nothing was working.


Finally, when entering the payload into a keyword field using JSON output instead of query-string we received a 200 response. Unfortunately, this field wasn't susceptible to the original XSS. We returned to the original field and, by changing the request from a string to JSON, received a 302 Found, signifying successful WAF bypass. However, the payload data wasn't persisting on the keyword page. Employing a parameter pollution tactic, we outsmarted the web application into saving the data and triggering the XSS with the following payload:


{"my_header": "xxxxxxx"}&key_word1=X&key_word2=Y&key_word3=”>< img+src=1+onerror=alert(1)>&my_header=test


Armed with a functional XSS, the team set its sights on exploiting CSRF. The application generated a CSRF cookie with a random value:


Set-Cookie csrf=8o3g2ksl4kll40b2; Path=/


The mechanism dictated that if the correct value was present in the header, a request would be accepted; otherwise, it would be forbidden. However, a revelation came to light since it was discovered at onlinestore/osx/index/keywords that deleting the CSRF header still allowed the request to go through.


Synthesizing this knowledge into a POST request and saving a POC.html file, our team achieved a successful exploitation of an XSS attack with both WAF and CSRF bypass. A visitor to the site would unwittingly find themselves redirected to our malicious domain. The journey through these vulnerabilities showcased our team's persistence and ingenuity in the realm of web application security.


 
 
bottom of page