The Open Web Application Security Project (OWASP) is an open-source application security project with a community that includes corporations, educational organizations, and individuals from around the world. This community works to create freely-available articles, methodologies, documentation, tools, and technologies. The knowledge and guidelines on this document are meant to be best security practices all web designers and web developers should follow to ensure their web applications are not vulnerable to common attacks and their users are kept safe. If you are a software developer and you write web applications you should take OWASP guidelines very seriously and make it part of your SDLC and code review process, if not there already. As with any other guideline, this is a living project and threads evolve everyday, so the guideline evolves everyday as well. Please be sure to read and keep yourself up to date with the most recent and accurate information about security standards and guidelines through the information provided in the OWASP website, online forums, papers, and various magazines that often publish security articles such as MSDN, VS Mag and Communication Arts.

OWASP has a project called 'The OWASP top ten project'. This project publishes every 2-3 years the top ten threads, security flaws and attacks web applications are victim off. All developers and project managers should take time to read and understand this list. If you discover new flaws that have not been managed previously in your web applications, do not waste time to discuss it with your peers and come to a resolution sooner rather than later. Entire companies have gone bankrupt or lost a valuable market share because they didn't pay enough attention to the security on their website and information was either compromised or completely gone forever due to hacker attack.

The OWASP List

This is a compressed list of my top 12 issues, they are common threads and attack strategies followed by hackers and how developers should prevent them. They are comprised by the last top 10 from the 2010 list, and another 2 from the 2007 list. Most of the 2007 list are repeated throughout the top 10 of 2010. They all have references as to what they are with a direct link to the OWASP site that contains more details about each thread.

1. Cross-site scripting (XSS) -- Applies to: 2007-A1, 2010-A2

  1. Avoid JavaScript running from 3rd party sites.
  2. If using jQuery and have CDN's sources, make sure the declaration is written on each http page and your CDN is a popular one, like the Microsoft or Google CDNs.
  3. Avoid places that allows embedding JavaScript code. If the web application has input controls, make sure they are ALL fully validated. Parse escape characters and other entries that are not allowed in any of them.
  4. Try to ensure your web application ignores all outside domain JavaScript remote procedure calls.
  5. By using SSL and the aforementioned JavaScript security checks, conditional XSS will never happen.
  6. Web applications using WCF technology should always use a secure binding such as netTcpBinding or ws-HttpBinding with transport layer security.

2. Malicious file execution -- Applies to: 2007-A2

  1. NTFS file permissions prevents unwanted file execution.
  2. Make sure the database process (SQL Server, MySql, Oracle) is NOT running under a local system account, but instead it runs always under an account with limited credentials. Never leave the database process running under full trust account like 'sa'.
  3. For ASP.NET deployments, make also sure the ASP.NET process does not run under a local system account, but instead it runs always under an account with limited credentials explicitly created for your ASP.NET process.
  4. Disable file execution ALWAYS on your database server (particularly important for SQL Server and Windows Server deployments).

3. Insecure direct object references -- Applies to: 2007-A4, 2010-A4

  1. Never show internal identifiers of customer records, tables keys, database object names and transactional records identifiers in any part of the web application, including the address bar. Potentially compromising data should not be exposed on the client side.
  2. Never expose object references to be consumed by the users. This should be an internal rule and should not be violated. In the case that the obvious approach is to expose object references, use tokenization and internal private mapping instead.
  3. Make penetration testing is part of the beta-test for all web applications prior to stable release to the public.

4. Cross-site request forgery (CSRF) -- Applies to: 2007-A5, 2010-A5

  1. If you have authentication on your site and have pages where  any financial or sensitive information is transmitted, you should always require access to such pages through TLS/SSL.
  2. If your application is a ASP.NET applications, let ASP.NET maintain the ViewState. This is a good approach to prevent an attacker to forge a valid Viewstate. ASP.NET controls vulnerable to CSRF attack are run in the server runat="server"
  3. The reasons for an attack of this type are very similar to those for a XSS attack. Please read how we prevent before in this post.

5. Information leakage and improper error Handling -- Applies to: 2007-A6

  1. Your web application should never exposes debugging messages, stack traces or path information to the browser. Instead, you should create a friendly application wide Error Page and 404 Page to be render in the browser in case of unexpected behavior or exceptions occur.
  2. Never expose private information of your users to another user. This is a common error among developers, where they try to prevent user duplicates and end up sharing more than it is needed to a prospect new user of your web site... "Are you John Smith from 555 Pen Ave?" NEVER DO THAT.
  3. Clear all sensitive information on every post back. Things like credit card information, PAN, Address, Billing, etc should not be persisted in between post-backs. Use JavaScript to validate this input fields to prevent full server round trips and ease user frustration when making errors on those pages.
  4. Internal DB identifiers should never shown to the user in the application: "Your customer id is 56457" and that is the actual primary key of the Customers table. NEVER DO THAT.

6. Injection flaws: SQL injection, LDAP and Xpath injection flaws, other injection flaws -- Applies to: 2007-A2, 2010-A1

  1. Filter escape characters of known SQL injection attacks. Use validation schemes to ensure data going into queries does not contain any attacks.
  2. Always remove bad or unsafe user input by means of sanity methods before executing any queries in your databases. There are plenty of good sanitation algorithms and methods on the web for this purpose.
  3. Use parametrized queries and store procedures are used when interacting with databases.
  4. Use a DAL implementation that relies on industry best practices. For example, if building web apps with ASP.NET/C# you can use the fantastic Microsoft Enterprise Library or Entity Framework to ensure consistency, security and best practices.
  5. Enforce least privileges when connecting to databases and back-end systems.

7. Broken authentication and session management -- Applies to: 2007-A7, 2010-A3

  1. If end users must change passwords, they have to re-authenticate, even if they have a valid session id.
  2. If a web application provides public authentication to end users, provide a locking mechanism where users are restricted to a maximum of 5 failed attempts of authentication per hour/day/whatever. Have something for this and log the failed attempts.
  3. Never store clear text passwords in your database of configuration files. You can use simple proven cryptographic solutions like the use one-way password hashing.
  4. User authentication credentials should be protected by transaction using SSL in all login and account management pages.
  5. Also refer to XSS and CSRF entries.

8. Insecure cryptographic storage -- Applies to: 2007-A8, 2010-A7

  1. Always encrypt sensitive data using industry standards cryptographic algorithms approved by National Institute of Standards and Technology (NIST) and the NSA.
  2. In the unavoidable scenario that we need to store sensitive data in resident memory for a short period of time, DO NOT use traditional native types of the language of your choice. Most languages provide marshaling types that provide security of data while in memory. If using C# you can use the SecureString for memory persistence. This will prevent a hacker from doing a full memory dump on the target PC and grabbing all the clear text content you had saved in memory before.

9. Transport Layer Protection -- Applies to: 2007-A9, 2010-A9

  1. Whenever possible, have communication between clients and the servers always goes through Transport Layer security.
  2. Each request to the web server is individually authenticated and authorized.
  3. All pages available through a TLS/SSL are NOT available also over a non-SSL connection. IF YOU HAVE IT ONE WAY, PLEASE AVOID THE OTHER.
  4. Cookies are marked with the "Secure" flag.
  5. Sensitive data, reference objects and private identifiers should never be exposed through URLs.
  6. Get TLS/SSL certificates by a popular Certificate Authority, like VeriSign or Thawte

10. Failure to restrict URL access -- Applies to: 2007-A10, 2010-A8

  1. Consistently enforce access control in presentation layer and business logic for all URLs.
  2. Role based authentication is provided as a minimum for web applications with configurable policies. Authentication credentials should never be hard coded.
  3. Authorization is verified by the web server prior to delivering responses to any web request.
  4. Anonymous users should only have limited access to registration pages or general information pages if any.

11. Security Misconfiguration -- Applies to: 2010-A6

  1. Updates to all servers, OS, Web/App server should be planned ahead of time and notified to the clients and development team to assess possible impacts of the updates.
  2. Default Administrator passwords are immediately disabled after a new OS is installed (if needed).
  3. Maintain constant communication and give special attention to Framework updates, database servers updates, OS updates and any patches, security corrections or changes that affect each other.
  4. Stick with a Framework. If you are using .NET, embrace it. The use of .NET Framework provides a stronghold architecture to build software. The same is true for other fantastic frameworks. Having too many frameworks means you need to focus on more content to maintain, which ultimately becomes very hard unless you have dedicated teams for it.
  5. Prior to any roll make a detail testing of the applicable updates in conjunction with applications. The same process should happen for new application updates and patches. Depending on the complexity of the application or update being deployed, more time may be needed. Do not rush the deployment of applications due to deadlines, we are better safe than sorry.

12. Unvalidated Redirects and Forwards -- Applies to: 2010-A10

  1. Avoid using redirects and forwards.
  2. In the inevitable need of using redirects, be sure you enforce authorization of parameter values used by the end users. Instead of actual values, protect your redirects with server mappings for the parameters passed in.

That's it. Obviously this was a rapid overview to the most common threads. You can find a lot more at www.owasp.org with a lot of good advice as well.

Happy coding!

Comment