OWASP Top 10 RC
OWASP is getting ready to finalize a new Top 10 list for 2010. The request for comments ends on December 31, 2009. In the beta version, there are a few items worth noting about the new list. Injection vulnerabilities look like they will overtake the number one spot on the list. Here is a quick rundown of what was added or removed.
Added
Security Misconfiguration – this applies to the configuration of the application itself, and all frameworks or servers associated with it. WCF has moved a lot of information into the configuration files and it is very easy to make a mistake. It is important to make sure that not only are servers patched, but also any libraries or third-party components.
Unvalidated Redirects and Forwards – it is important that when redirecting users, input is validated correctly. Make sure you know where the uri is coming from and that it cannot be tampered with by outsiders.
Removed
Malicious File Execution – this was largely associated with PHP applications, but PHP has been updated. Frameworks are being shipped with more default security turned on to help protect against this. Just because this is off of the top 10, it should not be overlooked. It is still a very dangerous item.
Information Leakage and Improper Error Handling – this involves blocking stack traces and other internal only messages from being sent to the client. I believe that this is still a very important issue because it can lead to disclosing important information, like directory structures or database schemas. I see this type of vulnerability regularly, so beware, it is still a high priority.
OWASP has done a great job of putting together a power point and a pdf document outlining the top 10 list. I encourage you to take some time and read over their materials. OWASP top 10 can be found at http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Solving the Unknown
As a developer, I run into new things everyday. I mostly work with Microsoft .Net technologies and it feels like an endless pit of information. Most developer’s feel confident about what they know, and tend to leave the unknown alone until they need it. Although I feel pretty knowledgeable about .Net, I have no problem admitting there are many areas of the framework that I do not understand or probably even know about. Not knowing an aspect here or there does not make a bad developer, it just means I may not have a need for that information at this time. What if I did need that information, but I just didn’t realize it? How does one know that they need to learn what they don’t know when they feel confident that they know enough to solve the problem? Confusing right? This is a very tough situation to be in. In development, there are a lot of ways to do everything. Some ways are simple, while others are very complex. When I receive a defect to work on, I do my best to solve the problem the best way I know how. This is a good effort on my part, but what if the solution is not whole because I don’t understand a portion of the defect? I may fix the code, run my tests, and consider the defect resolved, but do I really know if it is completely resolved? I guess that experience and working with other good developers is a good response to that question. We learn from our experiences and take those with us down the road.
I have thought a lot about this topic lately because I have come across defects that are not completely resolved. They passed the unit tests, but the tests do not wholly cover the problem. This is not due to a lack of effort from the developer working on the defect, just a lack of understanding of the true issue. So how do we solve the unknown? I think that doing a more thorough analysis on the defect is the beginning. Many times, the defect is reported and assigned and it is up to the developer to determine the cause. The next step is having someone that fully understands the issue and resolution to be involved. Finally, getting multiple resources together to review the final solution. Some solutions may require resources from different departments. Maybe someone from the business unit will be required, maybe someone from infrastructure. It is important to be able to identify the resources needed to correctly resolve defects the first time.
IE8 XSS Protection
While testing a cross site scripting vulnerability I ran into an interesting feature in Internet Explorer 8, the Cross Site Scripting filter. I was surprised when the browser popped up this message: “Internet Explorer has modified this page to help prevent cross-site scripting.†This really intrigued me, so I started looking at the source of the page. The first thing I noticed was that the browser had modified my page and replaced the first character in my script with a ‘#’ character. Here is the query string I had passed to the page:
?id=’ onClick=’alert(“hiâ€);’ title=’
The id parameter gets written as an attribute to a link tag. The expected result would be that my link tag would end up looking like this:
<a href=â€â€ id=’’ onClick=’alert(“hiâ€);’ title=’’>
This output would create an alert message when a user clicked on the link. This obviously doesn’t do anything spectacular, but it is a simple test when testing XSS. I am happy to see that Microsoft is taking steps to help protect users from this type of attack. Most users do not take a close look at the url that they are clicking much past the domain name. Although this does not provide full protection against cross-site scripting attacks, it is another layer for the attacker to have to fight through.
I did a few quick tests and found some interesting side effects of this filter. I will include that information after I get a chance to do a little more testing.
ViewState: Encrypted or Encoded?
Filed under: Security
One of the many ways to maintain state within an ASP.Net application is to use the ViewState. ViewState is sent to the client embedded in the HTML response. The ViewState can be found by viewing the page source and looking for the hidden __VIEWSTATE tag (seen below).
<input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE”
value=”/wEPDwUJNzgzNDMwNTMzDxYCHglGaXJzdE5hbWUFBUphbWVzZGTh6rDFbP6RwQU6igzX8
vn5IrEPyQ==” />
Looking at the ViewState above is misleading to most developers. The value looks encrypted, leading developers to think that it is secure. Unfortunately, the value is not encrypted, but encoded (Base64). When we decode the value it looks like this:
783430533[1]FirstNameJamesdd l :
There tends to be a lot of characters that are not printable, but the key values we are looking for in this example are the “FirstName” property and its value of “James”. This property was set in the code behind below:
ViewState[“FirstName”] = “James”;
This example shows how important it is to consider what data is stored in ViewState. Sensitive data should never be stored in ViewState, and if absolutely required, it should be encrypted with a strong algorithm.
There are a few properties associated with ViewState that are worth learning about:
These properties have great descriptions on MSDN. I encourage you to view the details about them if you are working with ViewState.
IE8 Not Saving Login Credentials
Filed under: Uncategorized
IE has always been able to save and automatically log in to sites requiring your domain credentials. In previous versions of Internet Explorer, you would set the site as a Trusted site in Tools…Options…Security by clicking the Trusted Sites icon and adding the url to the sites list. Once entering your credentials and checking the Remember Credentials checkbox you would not be asked to login again on that site. In IE 8 this does not appear to work the same way. Instead of setting the site as a Trusted Site, you must add it to the “Local Intranet†site list. Once you add the site, restart IE and this should resolve the issue.
ValidateRequest Property (XSS)
There is no doubt that while working with ASP.Net you have run into the ValidateRequest property for a web form. This is a feature that has been around since version 1.1. It prevents the server from accepting un-encoded HTML data, which can be used to exploit client-side attacks like Cross Site Scripting (XSS). The most common example of cross site scripting is to enter <SCRIPT>alert(‘exploited’);</SCRIPT> into a textbox on a form. If this textbox input is used as direct output to the web browser, it could produce a message box displayed to the user saying ‘exploited’. This is just a basic example of XSS.
ValidateRequest is here to save the day, or is it? In this post, I will take a deeper look at how ValidateRequest works and how it doesn’t work. My purpose is to give other developers a deeper understanding of how security works in .Net so they can write more secure applications.
In the 1.1 Framework, many developers would turn off the ValidateRequest page attribute because it was too restrictive. Getting constantly bombarded with an error message every time we sent a request was unavoidable. The below list shows the list of items that trigger the Validation error in the 1.1 Framework.
1.1 Framework Validation:
- &#
- <alpha, <!, </
- script
- On handlers like onmouseenter, etc.
- expression(
- Looks for these starting characters (‘<‘, ‘&’, ‘o’, ‘O’, ‘s’, ‘S’, ‘e’, ‘E’)
This is obviously a pretty strict list of items that would trigger a validation error. In the 2.0 Framework, Microsoft decided to loosen the restrictions on this quite a bit. Below is the list of validation checks in the 2.0 Framework.
2.0 Framework Validation:
- &#
- <alpha, <!, </, <?
- Looks for these starting characters (‘<‘, ‘&’)
As you can see, the validation checks have greatly decreased. The 2.0 Framework validation has carried over into the 3.0 and 3.5 Frameworks as well.
These differences are very important to understand. Not only should we understand what criteria the validators are looking for, but also where that opens security holes. If we are working with a 1.1 Framework application, it is very possible that the developers have turned the ValidateRequest off. This forces the developer to do all the work. When working with the 2.0+ Framework applications, there is a higher probability that the developers have left ValidateRequest on. This allows the framework to do some of the work. The important point here is that ValidateRequest on in 2.0+ will NOT prevent all Cross Site Scripting attacks.
Looking at the two lists above, we can see that malicious users could enter expressions or events into parameters and, under the right circumstances, get those events to fire in the client. This post is already quite long, so I will show how this can be done in another post. It is important to realize that ValidateRequest does not completely protect against XSS. There are other factors that must be considered. Microsoft has the Anti-Cross Site Scripting Library that might be a good idea to implement as well to help protect your application. I will take a look at this library as well.
CSSLP Certification
This week I achieved the CSSLP certification. This is a new certification by (ISC)2 for Certified Secure Software Lifecycle Professionals. The focus of this certification is on building security into the software lifecycle to help build more secure software. I have been focusing on security during software development over the past 5 or so years and believe that this is a good step for helping promote this idea to other developers.
Logic Error?
I was reviewing some code the other day and I came across an interesting section. The code is written in C#.
public void DoSomething()
{
if( 1 == 1 );
{
// Do Something;
}
}
What might not be immediately obvious is that there is a semi-colon terminating the IF statement. This function will compile. It will give you a warning, but it will not stop you from running the code. When this is run, the block after the if statement will always run. This is because the if statement is terminated and the block is just a valid block of code (often used for scoping variables). If this was logic for access to features, it could be easily overlooked and everyone would have access to the features. Of course, the testers should catch this type of error, but what if they didn’t? There may be a case where you would want to code a statement like this (maybe with a different if clause), but most cases would not want this design. This proves a strong point to glance over the warnings that the compiler throws. I felt this was an interesting code snippet I saw and wanted to share it with anyone else that may come across this one day.
Security Awareness
I have been working with application security for the past few years while doing my normal day to day development. I am very active in the security community and it always blows my mind how many developers are still uneducated about security. I believe that the trends of the hackers has moved from attacking the network to attacking the applications on the network. This is becoming more evident with the attacks that are cross browser and multi-platform. The industry has been pushing for products to designed with security in mind from the beginning, but that is far from happening in the “real world”. I have worked for quite a few companies and can attest that this is not always true. Businesses want to make money. Bottom line. That means that they want the product shipped as soon as possible. This usually cuts out the time to actually account for unbeatable security. A task that is impossible anyway.
Does this mean that we should not make the effort to do the simple things that are not high cost and time intensive. For example, there are still many applications that use dynamic SQL queries. It does not take any longer to use parameterized queries as opposed to just joining the string together. Sure, maybe you took the extra keystrokes to escape the apostrophe, but that does not provide foolproof security.
What about encoding the output that is sent to the browser. One of the biggest rules is to not trust inputs. That is not just the input from the user, but also from other components or the database. One should never assume that the data from the data store is clean. Encoding the outputs can make a huge difference in the security of your application. It is the biggest step to handle XSS.
Should all developers be expert hackers at ripping apart an application? No. I don’t think it really has anything to do with your ability to break a system. It has to do with your ability to understand how the attacks work, and what steps you can take to prevent them. Many of the techniques used do not take a lot of extra time to implement. Depending on your environment, some of the steps may be taken for you. ASP.Net controls will encode the values for you. It will also detect script tags on input forms (unless you turn that off). ASP.Net does a good job of starting the security practice, but does not cover it all. There are still many items that can be done to protect your code and data.
I hope to be able to provide some information in the next few posts that help developers get the right amount of information to perform their daily tasks.
Change in Scenery
I recently started a new job after spending the last year doing consulting work for a local company. Unfortunately, the recession has slowed work down a bit and I felt the best thing I could do for my family is to get a little stability into my career. I guess it is difficult to really feel stable in any market right now, but it is a little better than just being out on my own.
My change was from the laid back lifestyle of working from home three days a week to the requirement of being in the office eight hours a day, five days a week. It definitely takes some getting used to. The environment is getting better. The first week or so was a little crazy as I worked to get my system running correctly and the management worked to get me some work.
I have walked into a fairly large project and get the opportunity to work with both C# and VB.NET. I was previously working with C# and VB6 so the upgrade to VB.Net is a great feature. I have been working with both C# and VB.Net since the beta release, so it is not much of a culture shock to me. I don’t get as much time to spend on forums answering questions for others which is unfortunate. I feel as though I can make a positive impact on the new project so I look forward to the challenges that lie ahead.
Follow Us
