Post Security Virtual Conference Recap--Writing Secure Code Fundementals
Wow! It was great to see such a high attendance and have it be sustained through three sessions and four hours in total.
The three sessions were:
In this blog post I am going to recap and summarize some of the key points that we talked about today. Over the next few days I will create additional blogs that will cover areas that needs to be drilled into deeper based upon today questions and feedback such as AJAX, Code Analysis tools and where you can download a recording of today's virtual conference.
If you have not yet, please fill out the on-line evaluation for those that attended today's session. This is our first ever Security virtual conference and we want to make it better in the future.
You can also register for upcoming monthly (1 hour) security chalk talks at http://msdn.microsoft.com/canada/securitylockdown/...
Hacking Revealed
The first session today was examining and demonstrating the most common attacks that we are faced with today. Examples included:
- XSS
- SQL Injection
- BufferOverrun
- Canonicalization Issues
The most common attack today and will only likely increase in the near future with AJAX is Cross Site Scripting (XSS). For traditional web applications this is already a big enough threat and will become even more potent with AJAX. Stay tuned as I will be posting over the next few days on AJAX Security.
XSS occurs when the user of the Web Application is able to insert input that will ultimately be posted or echoed back to the Web Page. In the example I showed how a name and credit number value were required input and before proceeding with this fictitious application, the inputs had to be confirmed. The problem here was the values entered for both the User Name and Credit Number were not sanitized before being echo back to the Web page in a span tag. Therefore, an attacker instead of entering in a valid User Name could probe the site for XSS vulnerabilities by entering html or JavaScript such as <b>name</b> or <script>alert('you are being hacked')</script>. This was an example of non-persistent XSS scripting and leave some lead to defacing a site or stealing cookies, but first you would need to convince someone to click on a link such as false promise to win a prize in an email etc. Sort of a phishing attack.
The more dangerous of XSS is when it is persistent. This occurs when the value the hackers enters is saved into the backend resource such as a database. Therefore, if the input is not being validated and value being entered such as responses to questions like "Please give us your opinion on this product etc" is stored into a database and the value from this database field is read back into another Web Page. Therefore, the script is stored as ACSII in the database and is harmless to the database. But when a user clicks on a webpage that queries the database and retrieves the value then it becomes dangerous. As the browser is parsing the html and when it encounters the <script> or <img src=javascript:txt> tag in the database it will start firing off the javascript. Therefore, this type of attack will not affect just one user sessions but all users that happen to click on that webpage.
The second most common attack was SQL Injection. Similar to XSS this is where the user input is passed back to the database engine for processing. Therefore, if an input requires a datatime to do a search in a database then a valid datatime can be appended with additional SQL syntax. This becomes dangerous when the input value entered is appended to the database query with out any validation.
The third most common attack was bufferoverrun. This time the value entered by the end-user is passed onto the stack. If the input is greater than what then spaced stored on the attack and the function writing to the stack is a low-level language such as C and C++ then it is possible to overwrite the EIP or return address. Therefore, a hacker can craft up shell code and pass that in as input and have the EIP set to call the hacker malicious code. This becomes the most dangerous type of attacks as it could potentially allow users to run shell code that will format the harddrive, shutdown the firewall, create user accounts etc.
Finally, the last major example was canonical issue attacks. Basically there are multiple ways of representation characters in our applications. Therefore, if we are making decision by looking for a match of one or more characters in our code, then the attacker can bypass or deceive the decision making process by representing the characters in different a format such as hex values, double encoding or Unicode.
Mitigate and Detection
Therefore, when it comes to the mitigating and detecting these common types of attacks there are two major take-away.
- Never trust User Input
- Run under least privilege
Therefore, to prevent all the attacks from above, in your code you need various ways to validate the input and the validation needs to be done on server and not just the client.
- Client Side validation!=Security
- Client Side validation=performance
XSS can be prevented by a few techniques:
- ValidateRequest="true" in the page directive on ASP.NET 1.1 and 2.0 Applications--default setting
- HtmlEncode or URLEncode with either the Server.HttpUtility from the framework or the Anti-XSS library.
For SQL Injection Attacks the recommendations were:
- Parameterize Queries, and
- Filtering of Data via Regular, and
- Running under least privilege database account
Buffer Overrun
- Perform a null check and strlen on the input value -1 (the -1 accounts for the null value), and
- Run as least privilege account
Canonical Issues Defenses
- White Listing or Acceptance Listing--fail on the side of caution by filtering on characters accepted. This way the list is shorter, performs faster and does not have to be continually updated for every possible way a character can be represented like that used in Black or Deny Listing, and
- Use Regular Expression to filter for validate data such as only long file names.
Therefore, the morale of the story is to use multiple input validation techniques and never rely on just one as someone will find away around it. Finally, ensure your applications are running as least privilege therefore, the more harmful SQL Injection and BufferOverrun would fail due to a lack of permissions.
Use both a combination of code scanning tools and manual approach to find code vulnerabilities. There is no perfect code scanning tools and I like the saying Kevin Lam pointed out in today's presentation. Tools can not replace Humans and Humans can not replace tools. Regardless on what a code scanning tool vendor may tell you, there are no silver bullet, no simple solution. There will be a future blog on code scanning tools.
As Michael Howard and David LeBlanc points out in Writing Secure Code Edition 2, these security practices are like seat belts. Just because you use a seat belt you cannot drive at 200 km and expect to be safe in an accident.
Threat Modeling
Finally, the day wrapped up by looking at the new threat modeling tool by Microsoft ACE Team and how it can aid in documenting your applications and the potentials threats that may exists. Proper countermeasures can only be implemented when you truly understand the threats an application may have. There is no silver bullet countermeasure for all threats an application may face.
The threat modeling tool can be downloaded here and read the threatmodeling tool blog for additional information and videos.
Finally, the goal of today's virtual conference was to place the emphasize on writing secure code and that security is about acceptable risk through mitigation. There are no silver bullets and there is no such thing as 100% secure.
I leave you with this one last thought:
"At least when you physically secure a building you can usually see an attack, but on the Internet what you cannot see will HURT you. Securing applications is harder than physical security because you can not see the attack, how it is being done or when it is happening. You have no security tapes to review and to learn that an attacked even occured or what you can do to mitigate the attack in the future."
