OWASP Code Crawler is a .NET Windows Forms application built using Microsoft .NET C#, XML, Linq and few third parties open source components. Its development started in fall 2007 as a very simple prototype from a mail conversation between me (Alessio Marziali) and Eoin Keary (Code Review Project Leader and Board Member). Eoin spotted the hidden power of this tool and asked me if I could be interested in making it open source. Thrilled by the idea of joining OWASP, few months later Code Crawler became an official OWASP Project.

Over the years Code Crawler has substantially grown, mainly with the help of other volunteers around the world, and today I am very pleased to announce we have reached version 2.5. I personally want to thanks Tripurai Rai, Sasikumar Ganesan and Paulo Coimbra for helping me make this happen. In this release we have been focusing mainly on the UI of the application and also improved our database while introducing utilities like STRIDE, DREAD Calculator and ASP.NET ViewState Decoder. For a detailed list of features you can refer to the changelog attached at the end of this post.

License

OWASP Code Crawler 2.5 is a Creative Commons Attribution Share Alike 3.0 open source application which means you are free to copy, distribute, transmit and remix this code as you like. In this case, you must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license.

Download

OWASP Code Crawler 2.5 can be downloaded from http://codecrawler.codeplex.com. Please be advised that in order to run Code Crawler requires Microsoft .NET Framework 3.5. You may download it from here (link to Microsoft download website).

Changelog

• Code Crawler Editor
  • Find (CTRL+F)
  • Mark Findings
  • Select All (CTRL+A)
  • Copy as RTF (sweet)
  • CodeFolding
  • SyntaxHighlight
  • BracketMatching
  • Unlimited Undo/Redo buffer
  • Bookmarks
  • Go to line (CTRL+G)
  • Replace
  • Breakpoints
• Single Scan Form
  • New User Interface
  • STRIDE Classification
  • Direct links to MSDN and Google
  • Shortcuts to Notepad and Calc
  • Threats Count
  • Printing
  • RTF Report
• Visual Studio .NET (for VS 2005 - 2008)
  • Supports ONLY C# Project files (*.csjpro)
  • Bigger fonts
• Mainform
  • New User Interface
  • Links to OWASP content
  • WASC Threat Classification 2.0
  • Sun Java Guidelines
  • Removed OWASP Browser
  • Removed Network Scan
  • Removed Reporting Frame
• Database
  • 286 Keywords
  • Multi STRIDE Schema
  • Refactoring
• Utilities
  • ASP.NET ViewState Decoder
  • DREAD Calculator

What follows is a list of screenshots of Code Crawler 2.5. Code Crawler is more or less a new project today. We have taken the good and removed the bad. So far we have completed  STRIDE automatic classification, DREAD, Improved performances, Enchanted our database in terms of quality and quantity and most of all we said good bye to our previous UI.

Single File Scan new User Interface.

Visual Studio .NET (2005/2008) Integration is now fully working.

Code Crawler can now scan hundreds of files at the same time without leaving nothing behind. In this example Code Crawler has finished scanning a very busy Visual Studio Solution and an external file using single file mode. The user can switch easily between the result at any time.

Dread Calculator is an easy to use tool integrated within Code Crawler which makes Risk Analysis easy.

Code Crawler provides direct links to all OWASP major contents such as Guides and tools.

The single source code file form provides easy accessible options such as:

1. Archive (for reporting purposes and further investigations)
2. Print Source Code
3. Notepad
4. Calc
5. Google
6. MSN
7. Threats Count.

Download links, next week, hopefully.

Cross-site scripting attacks are on the rise because they are easy for attackers to craft and execute. In addition, they allow attackers to gather the most valuable content (user data) rapidly and in a manner that can easily go unnoticed by the user and often the Web site or application itself. As XSS attacks continue, it is imperative that development organizations prepare themselves with the solutions needed to rapidly address the problems as they occur. It is equally important that long-term solutions including security policies/requirements are in place to design, implement, verify, and release code that proactively protects your customers from XSS attacks.

Microsoft has released another document as part of their SDLC document library. This time is a 21 page document titled “Quick Security Reference : Cross Site Scripting”. The scope of this document is to increase awareness of XSS Vulnerabilities to each persona involved in software development. In particular Microsoft identifies four different roles: Business decision maker, architect, developer and tester.

Quick Security Reference Cross Site Scripting Reference also includes results of a basic survey of software companies that have established practices for fixing vulnerabilities that lead to attacks approximate that the costs associated with remediating a Web site that has encountered XSS like attack is around 40-man-hours per incident. That cost combined with the cost of hiring or training engineer to address the problem (~100$/hour) and the average number of seven XSS (or similar) exploitable vulnerabilities per Web site brings the total estimated cost to $28,000 to fix each problem reactively.

Figure 1. “12 Web application vulnerabilities between January 2006 and June 2007” shows XSS at the top of the ladder leaving no doubt that XSS is definitely one of the most exploited vulnerabilities in today applications.

Each persona is then introduced to different topics related to XSS, strictly related to their role and responsibilities. An architect will be more involved in Input Validation Rules, Output encoding strategies, Future Design Considerations rather then Identifying Untrusted Input and Writing Secure Code just to mention few. Useful insights on how to identify and classify an XSS type vulnerability (Reflected, Stored, Local) and software development best practices are also part of the document.

In conclusion; Software developers may find this document surprisingly useful as it covers almost everything they need to know in order to prevent, discover, mitigate and fix XSS vulnerabilities.

In fact, the hacker that goes by the alias “igigi” has published on the 15th of December on his blog the Rockyou database structure along with samples of the stolen data. The hacker claims he has downloaded over 32,603,388 (32 millions) user accounts.

Rockyou is currently making users aware of what happened and what they are doing in order to reduce the harm.

“We are investigating the data breach, reviewing our security protocols, and implementing new practices to prevent this from happening again. For example, we are taking the following steps:

1. We are encrypting all passwords;
2. We are upgrading the legacy platform with the same infrastructure and industry standard security protocols we employ on our partner applications platforms;
3. We are reviewing our current data security features and ensuring that they meet industry standards and best practices; and
4. We are cooperating with Federal authorities to investigate the illegal breach of our database.

We are sorry for the inconvenience this illegal intrusion onto the RockYou system has caused our users. We will continue to advise our users of any information that would help them.

What we can learn from this accident is quite obvious, SQL Injection is still one of the most popular threats, and of course, storing password as simple plaintext is definitely one of the biggest mistakes you can do while architecting a web application. This is why less than a month ago I was writing here on cyphersec.com a series of best practices aimed at increasing web application security. I’m sure I’ll add the Rockyou accident to the list of real world examples that proves why having plaintext passwords is a bad idea.

Rule 14# - Never compare passwords, compare the hash. Do not use MD5 which could be hacked using Rainbow tables, use RIPEMD160 instead.

Anyway, the worst part of the story is not the reputation of Rockyou which, obviously, has been hit hard - the problem is people still considering the side effects of non implementing application security as an inconvenient.

DarkReading           – Social Networking Developer Site Database Hacked In Sql Injection Attack
Owasp Foundation – SQL Injection Prevention Cheat Sheet
cyphersec.com       – Security Best Practices: ASP.NET Applications
cyphersec.com       – Toyo Tires, How to steal a database (Italian Language) 

With that said, Microsoft has released on the 13th of November a six paged document “Security Considerations for Client and Cloud Applications” via their Secure Development Lifecycle website. Surprisingly, the document doesn’t actually includes any advice for application developers nor for IT Managers considering moving their applications on the cloud.

It’s more just a  “Look. Here how we do cloud computing at Microsoft and, as you can see we do actually care about security. So pick us up” document.

The only interesting part of the document which is worth mentioning is  an overview of what the Operational Services Security and Compliance team within Microsoft does. OSSC team works across the operation, product, and service delivery teams and with internal and external auditors to ensure compliance with the relevant standards and regulatory obligations.

The following list presents an overview of some of the audits and assessments that the Microsoft cloud environment must undergo on a regular basis:

• Payment Card Industry Data Security Standard (PCI-DSS). This standard requires an annual review and validation of the security controls related to credit card transactions.
• Media Ratings Council. This relates to the integrity of advertising system data generation and processing.
• Sarbanes-Oxley (SOX). This legislation requires that selected systems are audited annually to validate compliance with key processes related to financial reporting integrity.
• Health Insurance Portability and Accountability Act (HIPAA). This act specifies privacy, security, and disaster recovery guidelines for the electronic storage of health records.
• Internal audit and privacy assessments. Assessments occur throughout a given year.

After analyzing all of these requirements, Microsoft determined that many of the audits and assessments required an evaluation of the same operational controls and processes. Recognizing the significant opportunity to eliminate redundant efforts, streamline processes, and proactively manage compliance expectations in a more comprehensive manner, the OSSC team developed a comprehensive compliance framework. This framework and associated processes follow the five-step methodology represented in the following illustration.

• Identify and integrate requirements. Define the scope and applicable controls. Standard operating procedures (SOPs) and process documents are gathered and reviewed.
• Assess and remediate gaps. Identify and remediate gaps in process or technology controls.
• Test effectiveness and assess risk. Measure and report on the effectiveness of controls.
• Attain certifications and attestations. Engage with third-party certification authorities and auditors.
• Improve and optimize. Assess and document the root cause of any noncompliance, and then track the remediation process. This phase also involves continuing to optimize controls across security domains to generate efficiencies in passing future audit and certification reviews.

Different Applications different level of security required

The security required will vary, depending on the type of system. For example, a government system dealing with millions of social security numbers will have much stronger requirements than a standard business application. Microsoft classifies systems as low, moderate, or high business impact to help determine security requirements and the strength of security features that they must provide. The categories take into account the relative potential for financial and reputational damage if the asset was involved in a security incident. For example, data assets falling into the moderate impact category are subject to encryption requirements when they reside on removable media or when they are involved in external network transfers. Data in the high impact category, in addition to moderate impact requirements, is subject to encryption requirements for storage and for internal system and network transfers.

For all cloud services that Microsoft offers, the documentation provided to users will always state what is protected and how it is protected. For example, users who choose to host their applications “in the cloud” may want to have their applications and processing protected from those of other users. For these users, Microsoft is committed to providing this level of protection. Additional security feature and protection requirements will vary from user to user, and from application to application, depending on data sensitivity and on applicable laws and regulations. Microsoft will be transparent about the strength and applicability of the security protections that its cloud services offer so that users will know what security features and processes are available, and will be able to determine how Microsoft will protect their data and processing. The information provided will enable users to evaluate the suitability of Microsoft’s cloud platform for their security requirements and to make informed decisions about their use of cloud services.

Download [docx] [microsoft.com]

The Microsoft Security Development Lifecycle (SDL) is an industry-Cleading software security assurance process. A Microsoft-wide initiative and a mandatory policy since 2004, the SDL has played a critical role in embedding security and privacy in Microsoft software and culture. Combining a holistic and practical approach, the SDL introduces security and privacy early and throughout all phases of the development process. It has led Microsoft to measurable and widely recognized security improvements in flagship products, such as Windows Vista® and Microsoft SQL Server®. Microsoft is publishing the detailed SDL process guidance as part of its commitment to enable a more secure and trustworthy computing ecosystem.

A new updated version of Microsoft Security Development Lifecycle has been released recently. The 125 pages whitepaper is a comprehensive set of guidelines aiming at making agile development and security best practices fit together for the first time.

In this release Microsoft indicates “7 Phases” as the hearth beating of the Security Development Lifecycle.

1. Training (Core Training)
2. Requirements (Define quality/bugs bar)
3. Design (Attack surface analysis – Threat modelling)
4. Implementation (Specify tools – Enforce banned functions – Static Analysis )
5. Verification (Dynamic / Fuzz testing – Verify threat models/attack surface )
6. Release (Response plan – Final Security Review – Release archive)
7. Response (Response execution)

For those who are new to SDLC and or to this whitepaper – read it. Anyone involved in professional software development should read carefully this document.

The Education and Awareness – Pre SDL Requirements: Security Training (for example) urge that all members of a software development team should receive appropriate training to stay informed about security basics and recent trends in security and privacy.

In fact, Microsoft suggests individuals who develop software programs should attend at least one security training class each year.

Security Training can help ensure software is created with security and privacy in mind and can also help development teams stay current on security issues. Project team members are strongly encouraged to seek additional security and privacy education that is appropriate to their needs or products.

The entire team should remain informed about security issues in the industry. Attacks and threats evolve constantly, and staying current is important.

Another interesting part, which is new of this version is the Security Code Review. And how it’s introduced to the reader.

Security code reviews are a critical component of the Security Development Lifecycle. Given the opportunity to review old code or work on a new cool feature, developers lean towards the latter. Unsurprisingly, attackers don't target only new functionality; they will attack all code, regardless of its age. Waiting to make the code more secure in the next version of the product is not a good solution for protecting customers, and therefore, high-risk items that are considered the most sensitive and important for security should be reviewed in depth at the earliest opportunity.

Microsoft suggest to determine the most-at risk components using the following criteria and perform an in-depth security review of the code making up those components.

• Priority 1 code is considered to be the most sensitive from a security standpoint. The following are examples of Priority 1 code, but please note this is not necessarily a definitive list. Pri 1 code is all Internet- or network-facing code, code in the Trusted Computing Base (TCB)—such as kernel or SYSTEM code, code running as administrator or Local System, code running as an elevated user (also includes LocalService and NetworkService), or features with a prior history of vulnerability, regardless of version. Any code that handles secret data, such as encryption keys and passwords, is considered Pri 1 code. For managed code, Priority 1 code is considered to be any unverifiable code (any code that the standard PEVerify.exe tool reports as not verified). All code supporting functionality exposed on the maximum attack surface is considered Pri 1 code by definition.
• Priority 2 is optionally installed code that runs with user privilege, or code that is installed by default that doesn't meet the Priority 1 criteria.
• Priority 3 is rarely used code and setup code. Setup code that handles secret data, such as encryption keys and passwords, is always considered Priority 1 code.

The document also includes loads of fresh new recommendations regarding both security and privacy. New techniques for protecting COM+ are also available.

Microsoft Security Development Lifecycle 4.1 [Download] [.docx]

How does a cross-site scripting (XSS) vulnerability occur? An example is when a web application does not encode the output that is sent to the browser, this can make the site susceptible XSS attacks as well as other common attacks.

Using XSS attacks, malicious users can cause damage to a site including hijacking a client session, stealing a web session information as well as cookies and more. The Anti-XSS Library v3.1 is an encoding library specifically designed to help developers protect their ASP.NET web-based applications from XSS attacks. Watch the video, “Anti-XSS 3.0 Released,” as Vineet Batta and Anil Revuru (RV), Senior Software Developers from the Microsoft Information Security Tools (IST), provide an overview of the Anti-XSS Library and how it can prevent XSS attacks in your application.

The key new feature in Anti-XSS v3.1 is sanitization of HTML pages and fragments, ensuring all malicious scripts are removed and enabling the input safe to display to the browser.

Download the latest Anti-XSS Library v3.1. Learn more about this library and other information security tools on the IST blog.

source : Information Security - Thoughts & Experiences from Todd Kutzke

Last Update: 2010/01/14

Securing web applications has always been a nightmare and probably it will always be. Working hacks for all major web development frameworks are into the wild and new vulnerabilities get discovered every day if not every hour.

Fortunately, .NET framework provides a good lists of defences that, if used and managed properly will allow you to create a defence wall between something valuable (your application) and the bad guys.

What follows is a list of all the .NET/ASP.NET security features, and best practices I’ve learned to be effective while coding web application during these years.

ASP.NET Application Security Guidelines

1. Security should not taken down in the name of simplicity and/or UI appeal.
2. Avoid, at all costs, client side validation (e.g. using Ajax or all JavaScript related validation libraries). JavaScript can and will, turned off and so your protections).
3. Validate everything that comes in. From HTTP Headers, to User Inputs (HttpHeaders, Cookies, ViewState and so on). Even if you don’t use them, keep an eye on them, bad formatted http headers could crash your web server for instance.
4. Assume that not only good guys will be using your applications.
5. Security through Obscurity never makes sense.
6. Validate user inputs in the application, promote the use of Regular Expressions (and be assured that they work the way they are meant to be)
7. If you are using AJAX, shield all your Ajax calls. Ajax hacking is a new kind of hacking into applications, be sure they are secure.
8. When using AJAX, be careful what you send back. Do not leak information. Do not return more information than is necessary to complete the request.
9. Use the principle of Encapsulation. Don’t abuse the public keyword. If something is marked as public there should be a valid reason for it. Promote the use of the internal and/or protected internal instead.
10. Pages with sensitive data should not be cached: page content is easily accessed using browser’s history.
11. Use Declarative and Imperative Security and don’t trust your own code. If your method is supposed to just read a file, use PermitOnly along with FileIOPermission.
12. Avoid using FullTrust, which means your application can do everything not only at application level by also at CLR level. Use Medium Trust or Low Trust depending on your application needs.
     

13. Use mature, well security tested algorithms.
14. Never compare passwords, compare the hash. Do not use MD5 which could be hacked using Rainbow tables, use RIPEMD160 instead.
15. Don’t rely on ViewState as a valid and secure storage. ViewState is by default base64 encoded, in a matter of seconds any clever hacker could hack it and use it against you. Encrypt it at page or application level using ViewStateEncryptionMode.
16. Make use of the HealthMonitoring system and trace your application behaviour. Use ViewStateFailureAuditEvent and make your application respond to such events.
17. Encrypt your connection strings using aspnet_regiis. This tool it’s so easy to use and requires simple steps to both encrypt and decrypt connection’s strings.
18. Promote the use of Gatekeepers, and never trust your application. If something have to deal with some other piece of code, it has to be authorised and authenticated first.
19. Don’t use Blacklists, but use Whitelists instead, teach your application what to accept not what to avoid.
20. Don’t try to sanitize a URI, if it doesn’t fit, reject it and let the user provide a valid one.
21. While creating a Web Service, use WSE. If you are using WCF instead, before writing an application on it read the WCF Security Guidance.
22. Don’t tell them anything. If your application throws an exception don’t provide technical details to the user. An hackers could read through the lines and craft a better working hack.
23. While storing a password or any sensitive string, use the SecureString object. Which is encrypted for privacy when being used, and deleted from computer memory when no longer needed.
24. Use platform features to manage keys where possible.
25. Do not pass sensitive data from page to page.
26. Do not cache sensitive data.
27. Do NOT use GET for anything that changes the server state or contains sensitive information. GET requests are logged in the web server access logs. They are also shown in the browser history.
28. DO use POST for every action that changes the server state and reject all non-POST methods. POST prevents unintentional actions, Most search engines won’t crawl POST forms and it also helps prevent duplicate submissions.
29. If using Cookies, mark them as HTTPOnly using System.Net.Cookie. Set the httpOnlyCookies attribute on the authentication cookie. Internet Explorer Service Pack 1 supports this attribute, which prevents client-side script from accessing the cookie from the document.cookie property.
30. Using slidingexpiration, is not always a good idea. A hacker could be possibly be logged in and won’t ever be kick out while trying to hack what’s next.
31. Do not echo any user input straight away. Encode it first. Do it only if required. ANY information you give to a hacker CAN and WILL be used to hack your website.
32. Learn how to use the Microsoft Anti-Cross Site Scripting Library to prevent XSS attacks.
33. Protect Audit and Log Files. Log files might be boring stuff to look at. From an hacker point of view, they are a goldmine as they could possible revel valuable information.
34. Don’t use Server.MapPath use Request.MapPath instead and mark the final parameter of to false. This means that a user cannot successfully supply a path that contains “..” to traverse outside of your application’s virtual directory hierarchy. Eg:

    Request.MapPath(INPUT, HttpContext.Current.Request.ApplicationPath, false);

35. Add safeguards to your ASP.NET application to help protect against common canonicalization issues using System.IO.GetFullPath at application level at the beginning of every request (Global.asax)

    

36. Use WindowsAuthentication instead of any custom authentication. Using WindowsAuthentication ensure you the password will never be transmitted over the network.
37. When constructing SQL queries, use type safe SQL parameters. AKA Use stored procedures or if you can not use parameterised queries in conjunction with Prepare statement. Using stored procedures it is always the best approach, from both technical and security point of views.
38. Robots.txt files are the first place hackers look at. Use access controls to protect them.
39. Secure your Web Service Definition Language WSDL. Your WSDL leaks the interface to your web service.
40. ASP.NET provides a very rich security features for protecting your pages against CSRF attacks. Using ViewStateUserKey in association with Session.SessionID as discussed here in the OWASP Cross Site Forgery Prevention Cheat. This value will be now validated in the postback and if the value provided does not match the value in the viewstate an exception is thrown. Note: This requires ViewState to be enabled and therefore cannot be used in ASP.NET MVC applications.
41. ASP.NET 1.1 and later include a ValidateRequest page directive that stops some malicious user input that could lead to XSS exploits. Since, ValidateRequest is enabled by default, all you have to do is ensure that you don’t explicitly disable it, either with page directives or configuration files. Note that ValidateRequest blocks any request that contain HTML or XML. If your page is intended to accept HTML or XML input from the user, you need to disable ValidateRequest, but be sure to follow the input validation discussed previously.
42. If you must use innerHTML to create elements in the document, create only those elements that are not available through the DOM (param is one example) or that are not generated by user input. To generate HTML elements, use the createElement, appendChild and setAttribute methods for greater safety.
43. If your site is constructed with frames, you can set the SECURITY attribute on untrusted FRAME and IFRAME elements to restricted. This set the security zone of the frame in the browser to the user’s restricted zone, which does not allow any script to run.

Web Server Security Guidelines

1. Deny extended URLs. Excessively long URLs can be sent to Microsoft IIS servers, causing the server to fail to log the complete request. Unless specific applications require long URLs, set a limit of 2048 characters. Microsoft IIS will process request over 4096 bytes long, but will not place the contents of the request in log files. Modify %windir%\system32\inetsrv\urlscan\urlscan.ini and ensure “MaxQueryString'=2048” is present. This requires URLScan to be installed (read below)
2. Use URLScan v2.5 or 3.1.
   URLScan v3.1 is a security tool that restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, URLScan helps prevent potentially harmful requests from being processed by web applications on the server. URLScan v3.1 has feature upgrades and fixes from its predecessor (v2.5) such as the ability to scan query strings, the ability to custom tailor rules that scan parts of your HTTP requests and many others. URLScan v3.1 will install as an ISAPI filter on IIS 5.1 and later, including the latest IIS 7.0 for Windows Server 2008
3. Disable Directory listing.
4. Your webserver should always be patched with the last updates.
5. Scan your webserver using tools like Nikto. Nikto is an Open Source (GPL) web scanner which performs comprehensive tests against web servers for multiple items, including over 3500 potentially dangerous files/CGIs.
6. Use SSLs were possible, this will encrypt and protect your data while on the wire. Using SSL doesn’t necessary means you are secure. It simply means your data is encrypted while on the go. If using SSL, restrict authentication tickets to HTTPS connections only.
7. Ensure that the application pool identity is not granted sensitive privileges or unnecessary rights to access resources.
8. Do not use highly privileged or administrative identities for IIS application pools
9. Consider using a lower privilege identity.
10. Separate code with different privilege requirements into different application pools
11. When using anonymous authentication, configure the anonymous user to be the application pool identity.
12. Use the principle of least privileged account. Create and associate your application with a low privileges user that fills all your applications needs.

SQL Server Security Guidelines

1. Disable access to the xp_cmdshell functions within SQL Server using EXEC sp_dropextendedproc ‘xp_cmdshell’.
2. Choose Windows Authentication when you can. It enforces strong passwords, password policies and other interesting stuff.
3. Use a least privileges user. Create a SQL Server login for the account. Map the login to a database user in the required database. Place the database user in a database role. Grant the database role limited permissions to only those stored procedures or table your application really needs. By using a database role, you avoid granting permissions directly to the database user. This isolate you from potential damage to the database.
4. If you are really paranoid, or asked to be, use the last line of defence. Database Cryptography.