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

Read part 4

 16. SQL Injection

SQL Injection is a type of code injection vulnerability that allows an attacker to interfere with the queries an application makes to its database. By injecting malicious SQL code, an attacker can read database content and thus gain access to sensitive information, modify or delete data, and in some cases execute administrative operations on the backed SQL server.

Bob injects the following SQL query to the email field:

bob@livemail.com' UNION ALL SELECT concat_ws(0x3a, version(), user(), database())--

Bob injects the following SQL query to the email field:

bob@livemail.com' UNION ALL SELECT TABLE_NAME FROM information_schema.TABLES WHERE table_schema=database()--

bob@livemail.com' UNION ALL SELECT email FROM carvibe_subscribers--

Bob's injected SQL query has successfully executed and returned the email addresses of all of subscribers!

17. Command Injection

Code Injection is a general type of attack that injects code that is then interpreted or executed by the application, usually due to missing or insufficient input validation. Command Injection more specifically refers to the injection of operating system commands, which often allow attackers to compromise the whole application, take full control of the server, and even attack other systems within the organization.

Review code:

var proc = Process.Start("cmd.exe", "/c curl -o -I -L -s -w %{http_code} " + API_URL + "?number=" + phoneNumber);

Bob modifies the phone parameter:

2-666-777-8888;xxx

Bob tries the following phone number:

2-666-777-8888;cat /etc/passwd

Mitigation

To effectively mitigate against Command Injection attacks, developers must avoid passing user-controllable input in functions or system calls that interface with the operating system environment or invoke third-party applications.

If this is unavoidable, development teams must perform rigorous input validation against all user-supplied data which includes:

- Validating against an allowlist of permitted values.

- Validating the input length.

- Validating that the input contains only alphanumeric values, ignoring all other escape characters or whitespace string. 

18. Token Exposure in URL

Exposed session tokens are a common and often overlooked security vulnerability caused when a user session id, API token or sensitive session data is included in a GET request. This can result in sensitive session data being exposed or logged by an application server e.g. web server logs, proxy logs or third-party analytics and monitoring applications and further increase the likelihood of session information being exposed to malicious actors.

Mitigation

Passing sensitive data such as API tokens within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers. Application URLs may also be posted on public forums, bookmarked or emailed by developers, thereby increasing the risk of invariably disclosing API tokens.

To effectively mitigate against exposure of API tokens in URLs, developers should use HTTP headers for transmitting API tokens. Examples of these headers include the following:

Authorization: <token_value>

X-API-Key: <token_value>

ProjectName-Api-Key: <token_value>

19. DOM XSS

DOM Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script so that the client-side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client-side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

Bob sends a malicious email to Alice:

Mitigation

To effectively mitigate against Document Object Model (DOM) based cross-site scripting vulnerabilities, developers must sanitize all untrusted data that is dynamically injected into the DOM.

For example, if client-side JavaScript is used to manipulate the content, structure, or style of a document's DOM element with user-supplied data, such input strings must be sanitized (encoded or escaped) for safe insertion into a document's DOM. 

Additionally, DOM objects that may be influenced by the user (attacker) should be carefully reviewed and escaped, including (but not limited to):

document.URL

document.URLUnencoded

document.location (and child properties)

document.referrer

window.location (and child properties)