9 Ways Hackers Exploit ASP.NET – and How to Prevent Them

Building secure ASP.NET web applications does not have the same glamor to it as building new, flashy features that impress managers and end users. However, glossing over security in the early phases of a build is a recipe for disaster. There is a tendency that it comes back and bites you when you least expect. And the consequences, as well as being embarrassing for the team involved, can have far-reaching implications for end user security and company-wide reputational damage.

Thankfully, as DevSecOps principles gain traction across engineering teams, we are seeing developers focus more on security in the initial stages of development, where once security aspects would have taken a backseat. At Apexon, we have championed security at all stages of development. It’s a vital foundation of any digital initiative, as our CEO outlined recently.

In this blog I am going to look at the most common types of ASP.NET attack and how to prevent them. Many ASP.NET MVC developers are highly skilled when it comes to delivering high-performance code, but unless security issues are top of mind at the early stage, they are leaving their applications vulnerable.

One great generic tip I can offer is to insist on clear audit trails when apps are built and run. This needs to become embedded into a team’s way of working so that if any issues occur, it is easy to track back to where they originate. It also means the team is not dependent on the developer who wrote that piece of code to fix the issue.

When I’m discussing preventative measures, I have assumed teams have access to the following tools:

• Visual Studio or Visual Studio Code
• Burp Suite Community Edition
• SQL Server Management Studio
• AntiXSS Nuget Library

1. Security Misconfiguration (Error Handling Must Setup Custom Error Page)

In this kind of attack, the attacker intercepts form data submitted by the end-user, changes its values and sends the modified data to the server. When the validations display errors, a lot of information on the server is subsequently revealed.

To demonstrate, I’ve created an employee form which takes basic employee details:

It’s tempting to think that data annotation validations are enough to secure the page, but they’re not. Here’s how these validations can be bypassed. By the way, if you’re new to validation using data annotations, I highly recommend this YouTube video.

Below is a screenshot that shows validation for the first name field asking for only 10 characters.

Now let’s intercept this form and submit it to the server from the intercept. I am using a tool called Burp Suite which catches requests going to and from the server.

In the below snapshot I have caught a request which is going to and from the server.

2. Cross-Site Request Forgery (CSRF)

A CSRF vulnerability allows an attacker to force a validated and logged in user to perform actions without their consent. Take this simple example:

• User logs in to the bank server.
• Bank authorizes and a secure session is established between the user and the bank server.
• The attacker sends an email with a malicious link saying “Earn $100,000 now” to the user.
• The user clicks on the malicious link and the site tries to transfer money from your account to the attacker’s account. Because the secure session is established the malicious code can execute successfully.

Microsoft recognized this threat and we now have something called AntiForgeryToken to prevent similar attacks.

3. Cross-Site Scripting (XSS) Attacks

Cross-site scripting (XSS) is an attack in which malicious scripts are injected via input fields. This extremely common breach allows an attacker to steal credentials and other valuable data that can cause big problems for businesses.

In the below example, an attacker visits a website and tries to execute a malicious script in a form comment box. If the website has not checked for malicious code, it can easily get executed on the server.

In the text box, I’m trying to execute some malicious code using JavaScript via the SCRIPT tag. But if we try to submit, MVC throws an error that something bad is happening.

Simply put, ASP.NET prevents a cross-site script attack by default.

4. Malicious File Upload

We’ve already learned how to protect input fields from malicious attacks, but we haven’t looked at file uploads. Attackers can change file extensions (tuto.exe to tuto.jpeg, for example) and the malicious script can be uploaded as an image file.

It is easy to get duped this way. The lesson here for developers is to remain alert to file extensions at all times.

5. Version Disclosure

Version information can be used by an attacker to help plan their next move. Whenever a browser sends an HTTP request to the server, in response we get a response header which contains all of the server information:

“X-AspNet-Version” shows information on which specific Asp.Net Version Used.

“X-AspNet Mvc-Version” shows information on which ASP.NET MVC version Used.

“X-Powered-By” shows information on which framework your website is running on.

6. SQL Injection Attack

An SQL injection attack is one of the most dangerous attacks, ranked first in a list of the top ten vulnerabilities as outlined by OWASP2013 [Open Web Application Security Project]. An SQL injection attack can give valuable data to the attacker that can lead to a big security breach and can also grant full access to the database server.

After trying a combination of SQL injection attacks, the attacker gets access to all user data. It is possible to display the SQL injection script in debug mode. Here we can see in detail how the attacker passed a malicious SQL statement that gets executed in the database:

7. Sensitive Data Exposure

All websites and applications have a database in which everything is stored, including user data like passwords, PAN numbers, credit card information etc. While encryption of all of this data is possible, we tend to only encrypt passwords, which can leave sensitive data exposed and vulnerable.

8. Broken Authentication and Session Management

If authentication and session management are not properly implemented in a web application, it will leave it vulnerable to attack. Attackers can steal data due to:

• Unsecured connections (not using SSL)
• Predictable log-in credentials
• Not storing credentials in an encrypted form
• Improper application log-out

Attacks can be carried out in many ways, but “session fixations” are the most common. When a user first sends a request to the server, the login page is loaded. After a successful log-in using valid credentials, we can assign some values within the session that recognize this user as a unique individual. An “ASP.NET_SessionId” cookie is added to the browser, and will relay data to the server on every request until the user logs out of the application entirely. Upon logging out, code is written that effectively ends the temporary session and removes the values associated with it, but the ASP.NET_SessionId cookie remains. This cookie can be used by an attacker to perform a session fixation attack.

To prevent this kind of attack developers should double-check that authentication and session management is properly implemented right from the start.

9. Un-validated Redirects and Forwards

In all web applications, we redirect from one page to another. It’s also common to redirect to another application entirely. But if we don’t validate those redirects, it can cause unvalidated redirects and the risk of a forwards attack. This attack is mostly used to phish the user for valuable credentials or install malicious malware.

For example:

Original URL: –http://localhost:7426/Account/Login

Crafter URL by Attacker: –?return URL=https://www.google.co.in

In this attack, the user gets an email from the attacker containing a tempting offer on an online shop, such as http://demo.com. However, upon closer inspection, we can see that the URL actually contains a redirect: http://demo.com/Login/Login?url=http://mailicious.com. If the user enters their valid credentials they’ll be redirected back to the shopping website and won’t suspect anything is wrong, but their details will have been stolen in an instant.

If you would like to learn how to secure your Asp.net Applications and how to overcome the challenges mentioned here, get in touch with Apexon using the form below.