Mitigating XSS Attacks in ASP.NET Apps

Most of the security analyst must be finding it difficult to completely eradicate chances of Cross Site Scripting Attacks. As far as Microsoft ASP.NET platform goes, it does provide a directive called ValidateRequest to check for input containing malicious code.

This directive was present since .NET 1.1 version. However, I find several cases where the application team deviates from having this directive set to true for some business reasons. For eg. there is a rich text box in the web page which must allow any kind of input data. If ValidateRequest is configured for this web page or for the application as a whole, it will throw HttpRequestValidationException before the input is even processed by your code.

So we started recommending that you must use output validation i.e HTMLEncode all data echoed back on web page. You could also use the new Microsoft Anti-XSS library.

In conclusion, ValidateRequest should be turned on if it does not block valid user scenarios. However, even with ValidateRequest turned on, it MUST not be regarded as a full proof solution to mitigate XSS.

Useful resources:
http://msdn2.microsoft.com/en-us/library/ms998274.aspx
http://msdn2.microsoft.com/en-us/library/system.web.httprequestvalidationexception(vs.80).aspx
http://msdn2.microsoft.com/en-us/library/ms998274.aspx

Cheers.

PCI DSS Applicability Information

* These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements for general protection of the cardholder environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.

** Sensitive authentication data must not be stored subsequent to authorization (even if encrypted).

SQL Injection in Stored Procedure : 2nd Case Study

Stored procedure with dynamic SQL and embedded parameters

The Stored Procedure

Create proc authenticate (@uid nvarchar(25),@pwd nvarchar(25))
as
DECLARE @uid VARCHAR(64)
DECLARE @pwd VARCHAR(64)
DECLARE @SQLString NVARCHAR(500)
DECLARE @ParmDefinition NVARCHAR(500)

/* Build the SQL string once.*/

SET @SQLString =
N'SELECT * FROM users WHERE userid = @uid AND password = @pwd'

SET @ParmDefinition = N'@login VARCHAR(64), @password VARCHAR(64)'


Server side code:

cmd.CommandText = "authenticate";
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add( "@uid", strUserName);
cmd.Paramerters.Add( “@pwd, strPassword);
con.Open();

string result = (string)cmd.ExecuteScalar();
oCon.Close();

In this case,bSQL Injection would NOT be possible. Hence what I would like to summarize is if at all we have to use dynamic SQL in stored procedure, always use embedded parameters in dynamic SQL

SQL Injection in Stored Procedure

Let us examine SQL Injection in Stored Procedure. This would be 1 of the vulnerable cases.

The Server Side Code would be something like:
oCmd.CommandText = "sp_login";
oCmd.CommandType = CommandType.StoredProcedure;
oCmd.Parameters.Add( "@loginId", strUserName);
oCmd.Paramerters.Add( “@password”, strPassword);
oCon.Open();
string result = (string)oCmd.ExecuteScalar();
oCon.Close();
====================================================================
The Stored Procedure would be:
CREATE PROC sp_login (@loginid nvarchar(25),@password)
AS
DECLARE @SQLString NVARCHAR(500)
DECLARE @loginid VARCHAR(64)
DECLARE @password VARCHAR(64)

/* Build the SQL string once.*/

SET @SQLString = 'SELECT * from cust_users WHERE login_id = '+ ''''+@loginid+'''' + 'AND password = '+ ''''+@password+''''

EXECUTE sp_executesql @SQLString

====================================================================

If the user input is as follows:
loginId = ' OR 1=1 --
password = junk

The above stored procedure will have an injection attack. The procedure executing will return all the rows because of the injected SQL.

Cheers.

Data Validation for App Security

Riding the Third Wave

HTTP Pipelines in ASP.NET

1. ASP.Net uses a pipeline model to process incoming requests and provide responses.
2. The steps in the pipeline are:

• HTTP Runtime
• HTTP Application Factory
• HTTP Application
• HTTP Handler Factory
• HTTP Handler

3. When IIS receives a request, it checks the extension of the requested page.
4. If the extension is .aspx, then it invokes aspnet_isapi.dll and passes the request to it
5. The aspnet_isapi.dll calls the HTTP Runtime object in the ASP .Net worker process
6. The pipeline is implemented inside this worker process (Aspnet_wp.exe)
7. The HTTP Runtime passes the request to the HTTP Application Factory
8. The Application Factory creates an application object for the request (or reuses an existing one) by looking at which application should be invoked
9. Every virtual folder is a different “application” to IIS
10. The HTTP Application objects contains modules or filters
a. The filters can be used inspect and modify HTTP requests and responses
b. For eg, to cloak the banner of the response, or filter out HTML or script tags in the request
c. Web application firewalls will be implemented as filters
d. The filters that are active for each app can be configured in web.config
11. The HTTP Application Object uses the Handler Factory to create the appropriate Handler to pass on the request
12. The HTTP Handler is the endpoint in the pipeline. It calls the .aspx page/assembly
13. The Handler has a method called “processRequest” that is called by the Application object
14. Custom handlers can be configured in web.config
15. An IIS web server will have only one asp.net worker process at a time
16. Each worker process contains multiple app domains
17. App domains are light weight processes running inside the worker process
18. App domains are .net “processes”, different from the Windows processes
19. Each application runs on different app domains.
20. These app domains enforce isolation.
21. When multiple requests are made to the IIS server, all of them are serviced by the same HTTP runtime and the same Application Factory.
22. The Application Factory creates new app domains to service concurrent requests

References:
a. Security and HTTP Pipelines in ASP.NET:
http://msdn.microsoft.com/msdnmag/issues/02/09/HTTPPipelines/default.aspx

Thick Client Application Security

This article discusses the top vulnerabilities in a two tier thick client application.

Thick client is defined as an applicationclient that processes data in addition to rendering. An example of thick client application would be a VB.NET or Java Swing application that communicates with a database.

I have generally observed in these types of applications have weak access controls, weak authentication management, information disclosure, improper error handling or application crash.

It is interesting to note that most of the Open Web Application Security Project (OWASP) Top 10 vulnerabilities are as applicable to Thick Client applications as they are to web applications.

Let us map them for simplicity.

Sr	OWASP Top 10 (Web Apps)	Thick Client
1	Unvalidated Input	Unvalidated Input
2	Broken Access Control	Broken Access Control
3	Broken Authentication & Session Management	Weak Authentication & Session Management
4	Cross-Site Scripting Flaws	Not Applicable
5	Buffer Overflows	Buffer Overflows
6	Injection Flaws	Injection Flaws
7	Improper Error Handling	Improper Error Handling
8	Insecure Storage	Insecure Storage
9	Denial of Service	Denial of Service
10	Insecure Configuration Management	Insecure Configuration Management

PCI Compliance bothering???

Hi,

When I was reading thru PCI DSS standards, something that was bothering me was the following requirement:

Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

* Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
* Installing an application layer firewall in front of web-facing applications.

This method is to be considered a best practice until June 30, 2008, after which it becomes a
requirement.

My confusion was whether I had to hire someone to go a code review or penetration testing or would other means work ?? Finally I could clear this by posting it to PCI and getting the answer.

What they mentioned was :
-----------------------------------------------

Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.

The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.

-----------------------------------------------

Finally, I could settle for the confusion. I need not go for a 3rd party review to go through several lines of code or do it myself. I can very well use tools like WebInspect and AMP to complete this requirement.

Cheers,
Dharmesh.

Westside in Mumbai stores your credit card numbers..

Hi,

If you are a Mumbai local, I am sure you would have visited Westside - one of the famous retail shops. I happened to bump into their store in Andheri(W) Infinity Mall and to my surprise, when I gave my credit card for swipe, they swiped it twice. :(
- Once on the processing machine and second on his computer.

I asked the fellow, "Why are u swiping my card twice?"

He replies, "Sir, we need to store your card information for tallying it at the end of day."
I was really disturbed by this. They stored my name, card number and expiry date. Only thing remaining was the CCV number. Remember this is generally a 3 or 4 digit number usually at the back of the card.

I am surprised that these merchants are allowed to store credit card information. No PCI compliance required ??

I felt like calling up the media - Mumbai Mirror, DNA or Times and yelling them that see these guys....what are they upto ?? Why the hell are they storing credit card information and if they need it, why is is not encrypted??

A hacker's mind would surely think of compromising their database having thousands and thousands of credit card holders information.

To add to all my fuss that day, they gave me a printed receipt to sign off and that too printed my entire credit card number (none of the digits were masked) and even the expiry date.

I am sure there are many such places in mumbai where credit card information is stored and is highly likely for hackers to get inside them very easily. If the merchants or shop owners do not bother to care about the credit card information, they must be banned from handling these transactions.

I wanted to raise my voice for all the people who actually opt for credit card transactions. Please make sure and shout if you find they are storing your credit card information. If they are swiping the card twice for their sake. This is illegal.

Visa / Mastercard and other card issuers must look into this matter asap.

Please send in your comments and let's raise this to get in media of possible and spread awareness.

Thanks.

Dharmesh.