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/...
The first session today was examining and demonstrating the most common attacks that we are faced with today. Examples included:
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.
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.
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.
XSS can be prevented by a few techniques:
For SQL Injection Attacks the recommendations were:
Canonical Issues Defenses
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.
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."