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!
Goal
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).
Description of code
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.
What’s wrong with that approach?
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.
What would a successful DOM manipulation attack look like?
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>).
So what?
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.
Main Takeaways:
- CSP-Nonce is a very helpful tool, but has to be properly used:
CSP-Nonce could definitely help prevent script injection, but it has to be properly used. In this case, the developer thought that by using the CSP-Nonce, the script would be protected from script injection. However, the developer didn't take into account that the URL parameter could be used to break the script tag and hence, change the intended flow of the code. Always make sure that the CSP-Nonce is used properly and ensure that the flow cannot be diverted skipping critical parts of code. Furthermore, never skip all the other security measures just because you have CSP-Nonce in place. In this case, using a different approach to include the name in the HTML could have been safer, such as using `element.innerText =` or similar which cannot change the HTML structure or break the balance. - Never skip user-input sanitization:
Especially when you choose to print an argument straight into the HTML, user-input sanitization is a very important step in securing your app. In this case, the developer didn't sanitize the URL parameter and hence, the attacker was able to break the script tag and change the intended flow of the code. Always make sure that the user-input is properly sanitized and that the user-input is properly validated before using it in a script tag.
Wanna join us on our next challenge? Sign up for our mailing list at wizer-ctf.com.
CODE WIZER!
Past Challenges
