If you're a returning visitor to our CTF Recaps, feel free to dive straight into the insights! For first-time explorers, let us quickly introduce you to the essence of these recaps. Wizer CTFs were introduced to challenge developers, encouraging them to adopt a hacker's mindset and thereby code more securely. This initiative is a pivotal part of our new security awareness training, specially crafted for development teams - Wizer's Secure Code Training for Developers!
After a challenge retires, our Wizer Wizard and CTO, Itzik Spitzen, crafts takeaways that offer valuable insights into the challenge, focusing on the defensive perspective for your script. Curious to test-drive a CTF before delving into the notes? Visit wizer-ctf.com – it's free, and there's something for all skill levels!
In this challenge, we're identifying a DOM manipulation caused by a working around the CSP-Nonce (Content Security Policy auto generated key intended to prevent script injection).
The code below showcases a simple page which shows the support contact information within the page and in an alert message. Since the developers were concerned of attackers altering this number, they protected the page with a CSP-Nonce header which is auto-generated by the server. The CSP-Nonce header is intended to prevent script injection by only allowing scripts with the nonce value to be executed. The page also has a form which allows the user to submit a message to the support team.
Outputting a URL parameter directly into a script tag opens up an opportunity for maliciously tinkering with the script tag and diverting the code flow.
By using the `name` argument to inject a tag which breaks the HTML tags balance, the script can be broken and prevent the next script from executing properly. In the following piece of code, the way the argument is used, allows an attacker to inject a balance-breaking tag into the first script container, which will cause the next script to break:
For instance, at the end of the `name` argument, which will now include the entire sentence after the word Hello: i.e. `Dave, our support phone number is: +91-56565-91919` an attacker could include a `<script>` tag which will break the next script and cause it not to run. To make everything work together, the phone number should also be wrapped in a named element (span) with the name `phone` so that the last piece of code, which runs at the end, would grab the new phone number for the alert (<span id="phone">%2B91-56565-91919</span>).
In this case, the DOM manipulation would be typically exploited to mislead the user into thinking that the support number is different than it actually is, and hence, the user would call the attacker instead of the support team. This could lead to a variety of attacks, such as social engineering, phishing, and more. In general, once attackers are able to divert the code flow within the context of a logged-in user, by using a phishing attack or other social engineering techniques, they could cause someone to click the link with the payload and execute an attack to perform actions on their behalf. This is just the entry point, once the attackers are in the system with any user’s credentials, they can then identify and exploit other vulnerabilities such as broken access control (a.k.a. IDOR), weak encryption / hashing and others to execute wider attacks.
Wanna join us on our next challenge? Sign up for our mailing list at wizer-ctf.com.