“Defend the Web” write-up (Library Gateway / Realistic)
“Defend the Web” write-up (Library Gateway / Realistic — JavaScript code exposure vulnerability)
Investigating, preventing, guarding, and resolving security concerns in JavaScript applications are all part of JavaScript security. Cross-Site Scripting (XSS), malicious code, Man-in-the-Middle attacks, and exploiting vulnerabilities in web application source code are the most prevalent JavaScript vulnerabilities.
The extensive use of public packages and libraries is another source of security flaws in source code. NPM, a major actor in the JavaScript ecosystem, has a registry with over a million packages. While the sheer variety is undoubtedly advantageous, it also implies that these packages loaded in web application projects may have a large number of hidden risks.
In this particular challenge, we will be exploiting JavaScript code exposure vulnerability, and try to gain access to the page. Without further ado, let’s get started.
Click on the “Library Gateway” button and view the redirected page.
Let’s inspect the source page and search for the word “password”.
Here we can see that the developers used JavaScript code for username/password implementation, and they gave us a small hint. If you noticed, there is a variable called “URL” and it is equal to a specific directory “members/” and username/password information are appended to it. Looks like we can tamper with the URL by adding the “members/” word to the end of the main path.
Once you hit “Enter” it should redirect you to the “members/” directory where you can find some interesting files.
If you go back to the source code above and inspect the URL variable, you’ll notice that structure is a little bit tricky. It uses a path of the URL, appends username, puts a space, appends password, and then adds “.htm” extension. So, the information in the “members/” directory kind of revealing itself. For example, let’s take a look at the “anna god.htm” file, “anna” is a username, then there is a space, and the word “god” is a password. Let’s try each one on the login page and find the correct credential.
Looks like the “librarian sweetlittlebooks.htm” file is the correct one. Use the word “librarian” for the username, and the word “sweetlittlebooks” for the password, and you should be able to pass the challenge.
Source code flaws are frequently paired with other, even many, JavaScript security flaws. Unfortunately, a single JavaScript obfuscation cannot prevent or hide these types of vulnerabilities in these situations. Because JavaScript is an interpreted rather than a compiled language, using this strategy to safeguard application code from prospective hackers would be nearly difficult. Obfuscation, on the other hand, is still a good practice because it slows down hackers’ reverse-engineering attempts.
The use of advanced scanning tools and the adoption of JavaScript security best practices can help protect apps and servers from JavaScript vulnerabilities.
In the world of online development, software engineers must always be aware of new JavaScript security threats. Not only is it critical to perform functionality tests on applications, but it’s also critical to use JavaScript security testing tools on a regular basis to avoid vulnerabilities. Finally, adhering to a few easy and well-known recommended practices will significantly improve the longevity of your apps.