Viewing entries tagged
security

Comment

WCF WTF!

It gets me when application frameworks tamper with core web concepts of precisely what they are trying to solve. If you have WCF services exposed through any of its different endpoints, you have to do the most ridiculous dancing to get something as simple as the HttpContext. WTF is up with that Microsoft!?!

There are like 10 different ways to access HttpContext and Request Headers, all weird in their own ways, none of them standard, and requiring the callers to add headers in different and specific ways:

  • There is HttpContext (or this.Context or HttpContext.Current): “Gets or sets the HttpContext object for the current HTTP request” This would be the obvious choice, but the WCF team needed to get COMPLICATED! To support this, you have to add extra magic and attributes to your service contracts (read here)
  •  Then we get fancy with something that is not quite the HttpContext the WEB knows and loves, but some new BS called OperationContext (OperationContext .Current). MSDN explains: “Provides access to the execution context of a service method”... but off-course!
  • Also HttpContextBase class according to MSDN “serves as the base class for classes that contain HTTP-specific information about an individual HTTP request”. So, you’d only think that HttpContextBase is the base class of HttpContext right? WRONG!

Hmmm, at this point you think this might be a brain teaser. There may be another 2-3 ways to access data from a similar concepts. If inspecting the HttpContext on the server side is a nightmare, managing headers and contextual http request elements on the client is even worse if your client is using the generated WCF contracts from VS. Here you are either setting something called ‘OutgoingMessageHeaders’ on an http request (like there is something that can be ‘incoming’ during a request), or you are implementing a custom IClientMessageInspector and altering the request before it is sent to the server: what is this the Police Academy (Inspector, pffff)? Why do I need to inspect a message I built? Or why am I forced to do this kind of crap?

This is so frustrating I cannot cope with the unnecessary layers of engineering and noise the WCF team threw over such a simple concept. I have nothing against new and different ways to solve problems, but please don’t call it the same as something that already exists and it’s well defined by the HTTP protocol specification (RFC 2616). PLEASE. DON'T.

I’ll try working around it with Rick Strahl’s post. If I keep having problems, I’ll move out to a different framework, implement my IHttpHandler, or downplay WCF’s capabilities.

Comment

Comment

OWASP Guidelines, what you should know.

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

1 Comment

Installing and using FxCop

This article is supporting the article “Definition of DONE” with regards of code analysis and best practices. FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework CLR) and reports information about whether the assemblies are abiding by good design guidelines and best practices. Things like architectural design, localization, performance, and security improvements are among the many things the tool will check automatically for you and give you a nice detailed report about its findings. Many of the issues are related to violations of the programming and Microsoft guidelines for writing robust and easily maintainable code using the .NET Framework.

On the home page of the tool says that "FxCop is intended for class library developers". Wait what? Class Library Developers? WTF, whatever...the fact is that the tool is good for any type of managed library, including service libraries, winForms and WPF projects. If it looks like a DLL, smells like a DLL, and it has extension "*.dll" or "*.exe" => FxCop will screen the hell out of it.

I also find FxCop a very useful learning tool for developers who are new to the .NET Framework or who are unfamiliar with the .NET Framework Design Guidelines. There is plenty of documentation online (MSDN) about the Design Guidelines and the different rule sets of best practices Microsoft recommends.

Think of FxCop as a bunch of Unit Tests that examine how your libraries conform to a bunch of best practices

FxCop is one of the tools I use to follow my Scrum definition of "Done" when writing code in .NET. But I also mentioned(wrote) about ReSharper Code Analysis features and how great they are and how we use them too. So the singular question becomes: WHAT IS THE DIFFERENCE BETWEEN FxCop and ReSharper Code Analysis?

The answer is simple:

  • ReSharper Code Analysis analyses your .NET language (C#, VB.NET) source code.
  • FxCop analyses the binaries produced by your source code. FxCop will look for the Common Intermediate Language (CIL) generated by the compiler of your .NET language.

In a sense, FxCop analysis should be done after ReSharper analysis, and will trap everything R# missed. FxCop was initially developed as an internal Microsoft Solution for optimization of new software being produced in house, and ultimately it made is way to the public.

Installing FX Cop

  1. Verify whether or not you already have the Windows SDK 7.1. If you already have the folder "C:Program FilesMicrosoft SDKsWindowsv7.1" on your FS, that means you have it; otherwise you need to install it. If you have it, skip the next steps.
  2. Download the Microsoft Windows SDK for Windows 7 and .NET Framework 4. You can download the web installer from HERE or search in Google for "windows sdk windows 7 web installer .net 4.0". Make sure you are downloading the one for .NET 4.0 and no other one.
  3. Install the SDK with the following settings
  4. Install FX Cop 10 by going to "C:ProgramFilesMicrosoftSDKsWindowsv7.1BinFxCop" and running the setup file.

Using FX Cop

There are 2 ways of using FxCop: standalone or within Visual Studio.

Using FxCop in standalone could not be simpler. It works similar to VS in the sense that you create projects where each project is nothing else than a collection of DLLs that are analyzed together (called targets in FxCop... why not, Microsoft).

To use FxCop as a Visual Studio tool:

  • Open VS and go to Tools->External Tools
  • Add a new tool and call it FxCop with the command line tool pointing to "C:Program Files (x86)Microsoft Fxcop 10.0FxCopCmd.exe"

Now without leaving VS you can either run it as a CMD line tool by going to Tools->FxCop OR you can configure your projects to enable code analysis when you build your project. Doing it the second way will allow you to get the errors and warnings on the same build output window you get compilation errors.

Wrap Up

FxCop is a very solid tool to enforce good practices on your projects and assemblies, and it offers a wide array of configurable features not on the scope of this article. Ultimately you can write your custom rules for FxCop and enforce them as part of your project code analysis. Visual Studio integration is also a great way to maintain your code as you write it.

For more resources on FxCop, check out the FxCop Official Blog.

1 Comment