OWASP Top 10: how to discover vulnerabilities in your C# applications

In this article, you will learn which are the top 10 security issues in web applications (called OWASP TOP 10). For each vulnerability you will get how to know if your code is protected against it and how to analyze it automatically. This post is the second part of another post about discovering vulnerabilities in a Java application.

OWASP

How can I detect vulnerabilities in my CSharp application?

The origin of OWASP vulnerabilities can be in any component involved in a web application production system, such as servers, network and connections security, accesses to related systems, etc. However, most of them can be prevented by writing source code which is secure and protected against potential threats. Kiuwan may help to detect insecure code that could be corrected to prevent a security problem in the future. Let’s review the OWASP TOP TEN to check which ones can be detected in coding phase using Kiuwan rules:

  • A1 Injection. Injection flaws, such as SQL, OS and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

There are several Kiuwan rules to verify that your code is not vulnerable to the most common security problems:

    • OPT.CSHARP.LdapInjection: Avoid non-neutralized user-controlled input in LDAP search filters.
    • OPT.CSHARP.SqlInjection: Avoid SQL code formed with non neutralized user input (vulnerable to SQL Injection attacks). More.
    • OPT.CSHARP.CommandInjection: Avoid non-neutralized user-controlled input composed in a SO command.
    • OPT.CSHARP.XPathInjection: .NET framework offers an API to execute a XPath search on a XML DOM tree. If the location path depends on non-neutralized user-input, a potential XPath Injection vulnerability could be present, enabling user control on the nodes returned by the XPath search functions.

 

If you’re curious about the #1 security issue, you can watch this tutorial:

 

  • A2 Broken authentication and session management. Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys or session tokens, or to exploit other implementation flaws to assume other users’ identities.

Kiuwan provides this rule to verify the correct use of sessions and authentication:

    • OPT.CSHARP.OftenMisusedAuthentication: It is recommended not to base the security of a system on DNS names. Many DNS servers are susceptible to attacks, if your software is running on an affected server, attackers could redirect your network traffic through their computers or make it appear that their IP addresses are part of your domain.

 

  • A3 Cross site scripting (XSS). XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites or redirect the user to malicious sites.

Most rules of the previous point prevent cross site scripting problems. But Kiuwan also provides this one:

    • OPT.CSHARP.CrossSiteScripting: Software places user-controlled input in page content. An attacker could inject browser script code that is executed in the client browser. The end-user is the attacked subject and the software is the vehicle for the attack. There are two kinds of XSS:
      • Reflected XSS: Attacker causes victim to supply malicious content to a vulnerable web application, which renders HTML content embedding a malicious script executed in victim’s browser. A variation of this is named DOM-based XSS, where the vulnerable software does not generate content depending on user input, but include script code that uses user-controlled input.
      • Persistent XSS: Attacker provides malicious content to vulnerable application, which is stored somewhere. When other user access to vulnerable pages that embed without proper neutralization the attacker content, script code is executed in the victim’s browser. For this, you should add other input kinds (e.g. file_input and/or database_input) to the ‘inputs’ rule property.The script executed in the victim’s browser could perform malicious activities, like stealing active authentication tokens (sometimes in the form of cookies) and performing operations on an insecure webapp (on behalf of the victim) that trusts too much identity artifacts in browser and do not request additional authorization for operations (‘Cross-Site Request Forgery attack’, CSRF). Many browsers could limit the damage via security restrictions (e.g. ‘same origin policy’), but user browsers generally allow scripting languages (e.g. JavaScript) in their browsers (disabling JavaScript severely limits a web site). For remediation, you must perform data validation (to ensure that user input is valid), data sanitization (to remove HTML tags from user input) and above all output escaping (to remove characters from user input that could make the browser interpret any part of it as executable code). To perform input validation, it is recommended to keep active request validation provided by .NET and constrain the user input depending of expected content.In order to escape output properly, context in which content will be rendered is the key because, depending on context, different techniques should be used:

        - HTML content.
        – Attributes in HTML tags.
        – JavaScript.
        – CSS.
        – URLs.

        Microsoft Anti-Cross Site scripting library is a powerful tool for escaping data. Besides an utility set for escaping data in your code, it provides the Security Runtime Engine, an HTTP module that hooks into the page lifecycle and encodes server controls before they appear on the page.

        Remember that the attacker may encode special HTML/JavaScript characters in rather imaginative ways to escape any “reject bad characters” validation strategy.

 

  • A4 Insecure direct object References. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory or database key. Without an access control check or another protection, attackers can manipulate these references to access unauthorized data.

Application code should protect unauthorized data access. Kiuwan helps with these rules:

    • OPT.CSHARP.PathTraversal: Software uses external input to construct a pathname that is intended to identify a file or directory located underneath a restricted parent directory, but software does not properly neutralize elements within pathname, which may cause the pathname to resolve to a location outside the restricted directory.
    • OPT.CSHARP.SystemInformationLeak: This fact occurs when system data or debugging information are exposed to third parties through a sequence of output or a log function.

 

  • A5 Security misconfiguration. Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server and platform. Secure settings should be defined, implemented and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

Prevent this vulnerability requires paying attention to the source code, but you can also keep in mind:

    • OPT.CSHARP.CookieSecurityHttpOnly: Internet Explorer supports HttpOnly attribute in cookies which prevents client-side scripts from accessing the cookie and therefore local or modify these values. Script attacks often access cookies in order to steal session identifiers or the authentication token. When HttpOnly attribute is not set or configured in Web.Config file using httpOnlyCookies attribute of httpCookies element, attackers can more easily access cookies of the user.

 

  • A6 Sensitive data exposure. Many web applications do not properly protect sensitive data, such as credit cards, tax IDs and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft or other crimes. Sensitive data deserves extra protection, such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

To protect sensitive data exposure, you must use secure protocols, like HTTPS. Kiuwan can help finding misconfigurations:

    • OPT.CSHARP.WeakEncryption: Current cryptography guidelines suggest that key lengths of at least 1024 bits should be used with the RSA algorithm. However, increased computing power and advances in factoring techniques[1] are challenging the security of 1024 bit RSA encryption.
    • OPT.CSHARP.WeakCryptographicHash: MD5 and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. Recent advances in cryptanalysis have discovered weaknesses in both algorithms. Consequently, MD5 and SHA-1 should no longer be relied upon to verify the authenticity of data in security-critical contexts. Techniques for breaking MD5 hashes are advanced and widely available enough that the algorithm must not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles heal for the algorithm and techniques for breaking it will likely lead to the discovery of even faster attacks.
    • OPT.CSHARP.CookieSecurityOverSSL: Modern web browsers support a Secure attribute in each cookie. If true value is assigned to this attribute or is configured in Web.Config file using requireSSL attribute of httpCookies element, the browser can only send this cookie through the HTTPS protocol. Otherwise, these cookies could be sent over a non-encrypted channel, for example HTTP, so they will be exposed to attackers that will be able to access confidential information or a session identifier. If an application uses both HTTPS and HTTP, but does not require SSL for cookies, cookies set during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.
  • A7 Missing function level access control. Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge them in order to access functionality without proper authorization.

Unfortunately, there is no reliable way of ensuring that each function is accessed by the appropriate user (based on their permission level), reviewing only the source code. This vulnerability, which depends closely on the functional requirements, shall be verified by functional and safety tests.

 

  • A8 Cross site request forgery (CSRF). A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests considered as legitimate requests from the victim by the vulnerable application.

As I commented in A3 and A5, Kiuwan can detect misconfigurations, as:

    • OPT.CSHARP.CrossSiteRequestForgery: When a user is authenticated in a web site, an attacker with a deep knowledge about the web site can perform malicious requests againts the vulnerable site and execute actions while user remains authenticated. Usually, the attacker achieve that authenticated user performs the malicious request using social engineering or exploting an XSS flaw of vulnerable site. In web sites developed with ASP .NET framework, anti-forgery tokens, also knowns as request verification tokens, must be utilized to prevent CSRF attacks.Anti-forgery tokens are random values generated in the server when a form is requested, and they are included in every request so the server can verify not only that user is authenticated, but anti-forgery tokens too. This rule applies to WebForms applications using forms authentication with cookies, and it checks:

      - EnableViewStateMac is active. From ASP .NET 4.5.2, it is not allowed to deactivate EnableViewStateMac and value of this property is ignored in runtime. If you are running in ASP .NET 4.5.2 or later, please use checkEnableViewStateMac rule property to avoid violations.
      – ViewStateUserKey in page class is utilized to store an anti-forgery token, in every page initialization, or anti-forgery is assigned in master page.

  • A9 Using components with known vulnerabilities. Components, such as libraries, frameworks and other software modules, almost always, run with full privileges. If a vulnerable component is exploited, such attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

 

  • A 10 Unvalidated redirects and forwards. Web applications frequently redirect and forward users to other pages and websites and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorized pages.
    • OPT.CSHARP.OpenRedirect: Avoid using unvalidated input to build the URL used in a redirect. The rule detects a path in code between an input statement (source) and a redirect statement (sink), to an URL depending on non neutralized input.

 

Remember that you can start using Kiuwan without charge starting today. I recommend that you sign up and begin to test whether your code is free of vulnerabilities. If you want to start testing with other code, OWASP provides you with an application called WebGoat. It is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons.