Cross-Site Scripting In Authenticated Panels

Cross-Site Scripting In Authenticated Panels

Cross-site scripting, or XSS, is one of the most prevalent vulnerabilities in modern web applications. XSS falls under A03: Injection on the OWASP Top 10 web application vulnerabilities. These vulnerabilities can lead to users having actions taken on their behalf and credential or session theft. Developers should know how to identify areas where XSS may occur and then understand how to prevent them from happening. This is not always easy, as, especially with large applications, it can be possible for certain areas to slip through the cracks.

Case Study

During this test, Blue Goat Cyber was tasked with performing an External Penetration Test for the customer. The test was small, and as a result, the attack surface was small as well. The size and complexity of an organization often directly translate to its security posture. The larger a network is, the more areas for attackers to exploit. The unauthenticated perspective did not turn up many major vulnerabilities during this test.

As part of a comprehensive test, it is important to check all levels of access. One of the hosts in scope for this test ran a web application with a user account functionality. Authenticated panels often have looser security controls as they are viewed as safer due to being behind a login page. This is not the case, especially when an attacker can make an account to the service. Care needs to be taken to secure all areas of an application.

XSS comes in 3 different forms: Stored, reflected, and DOM-based. Stored XSS is often viewed as the most dangerous, as it is persistent in the application. Reflected XSS is less severe, as it typically can only be reflected on the user inputting the malicious code. It is still important to prevent, as users may be tricked into doing it on themselves through social engineering attacks. DOM-based XSS works differently by modifying the server-side response instead of the client-side code, meaning the XSS is stored in the HTTP response sent by the application.

During testing, Blue Goat was able to identify a user information page where users could fill out basic information about themselves, such as their name and address. All fields had a maximum length to prevent long and often malicious strings from being injected. This is a good step when defending against injection attacks, though it should not be the only step. In this case, all validation was done on the client’s side. Because of this, all that was needed to bypass it was simply changing the length variable on the client-side JavaScript code.

Making that simple change allowed for longer strings to be passed into the application, including strings long enough for XSS.

Once the payload was injected into the application and the page was refreshed, an alert popped up, signifying that the XSS worked. This alert is meant to be a simple demonstration of what could happen, but attacks from XSS can be far more dangerous. Users can be prompted to visit seemingly safe websites that attempt to harvest sensitive data or have their credentials/session stolen and reused by malicious hackers.

Defending Against XSS

Luckily for developers, the defenses against XSS can be pretty simple to implement. The most important thing to remember is that validation should not be only implemented client-side, as this is trivial to bypass, as was shown here. Strings should be checked for their length and content before being passed into the application. There is no need to allow users to have a 200-character-long first name. It is also a good idea to black-list certain known malicious characters commonly used for XSS, such as angle brackets and parentheses.

Even if the input is being checked, the output should be encoded as well. User content reflected in an HTTP response should be encoded and sent with the proper tags to ensure users can not load in scripts, image files, or other commonly used XSS tags. It is also a good idea to implement a CSP, or content security policy. While this will not prevent XSS attacks from happening, it will make them much more harmless if they do occur.

Test Your Application’s Security With Blue Goat Cyber

Our team is highly experienced in many different areas of security. We can work with you to patch up holes in your applications and ensure that you deliver safe and secure products. Contact us to schedule a discovery session.

Blog Search

Social Media