Viewing entries tagged



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.



Killing all Cassini(s) with a .bat file

When working with Visual Studio and using the Web Development Server (aka CASSINI), there is often the repetitive task of killing the Cassini processes before running again. This happens especially if you are working with in-proc caching on IIS, or simply have many web applications in your solution.

What I do is run a simple bat file that automatically kills all the Cassini Web Development Server instances, that way if I need to make sure I'm using uncached data I just run it and keep on doing what I was doing before, instead of manually scanning my taskbar.

So, crack open notepad, write the following and save it as "CassiniKiller.bat"

[sourcecode language="cpp"] taskkill /F /IM "WebDev.WebServer40.exe" taskkill /F /IM "ProcessInvocation86.exe" taskkill /F /IM "iexplore.exe" [/sourcecode] Now you won't have to play cat and mouse with the Cassinis no more; now you just KILL'EM ALL :-)



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 with a lot of good advice as well.

Happy coding!


1 Comment

SharePoint? What is that?

The first questions people ask themselves when they hear the SharePoint Buzz for the first time is What the heck is SharePoint? I will explain in a friendly and simplistic way what SharePoint is, and how it has fold out to be one of the most powerful and fast growing software solutions in the history. Coming up:

  • What is SharePoint?
  • How exactly is SharePoint different from any regular web site?
  • How can SharePoint help you in your bottom line?
  • Conclusions

What is SharePoint?

From the technical-friendly point of view SharePoint is a software ecosystem formed by many different Microsoft software products. Microsoft indifferently refers to it as Microsoft SharePoint Products and Technologies. SharePoint (aka SP) targets the space of web collaboration functions, content and document management, search and social networking in one centralized solution that offers a plethora of very powerful business applications that are deeply tight to the already popular Microsoft Office applications.

From the end users perspective SharePoint is a web site (web application) that allows users to collaborate and share information, documents, photos and other media rich content directly from the web browser without needed to have any technical skill. Simply by using tools they already know like Microsoft Word, Excel, Power Point, InfoPath and such, users can create very rich documents and have them broadcast to a large audience with the click of a button.

Another important notation to make is that SharePoint is a cross platform product. That means SharePoint, being a browser based tool, can be experienced from many different operating systems like Windows, Mac OS-X and Linux systems. Although SP is a cross platform tool, as of today's official product (MOSS 2007) there are a few rendering abnormalities with some specific content in browsers different from Internet Explorer. Users accessing SharePoint sites with the popular Firefox browser, Safari, Opera and Chrome to name a few may experience that some controls and parts of certain pages will be rendered incorrectly in the page. This issue is not very common and will not affect the functionality and power SharePoint brings to its users. SharePoint 2010 is in beta stage as of the writing if this article and the SP Team announced most of the browser compatibility problems from previous versions will disappear in the upcoming release.

Browsers in SharePoint

If you are interested in diving a bit more into the browser war, SharePoint official compatibility and the Microsoft recommendations for browser support you can explore this TechNet article that is dedicated to such topic.

Ok, so how exactly is SharePoint different from any regular web site again?

As we mentioned before, SharePoint is a collection of software applications. These applications are Server products, meaning they were made to be run in a Windows Server OS. The combination of these products (Search, Forms Server, Excel Services, SSO, etc) provide SharePoint with many built in functionality that does not need to be implemented and can still be customized to a very granular level with very little IT support.

To better understand the difference between the SharePoint offerings and building and maintaining your own web site, we must first see what goes into creating and maintaining a web site. The following table shows some (I said SOME) of pros and cons of the most popular methods to build a web site and their pros and cons (Click to enlarge).

The "Web Site" in the title of the table is quoted, because the reality is that SharePoint offers a lot more than just a Web Site, it offers collaboration, networking and business tools to make any SP install a catch-all experience. Also is worth noting that technically SharePoint does not offers a Web Site, instead (from IIS perspective) it builds a set of IIS Web Applications that are linked and can exchange information via the SharePoint ecosystem. Hold on to your hats, more on that and the SharePoint terminology later.

As you can see there is plenty to eat in the SharePoint family. But how does it directly affect you?

How can SharePoint help me as an organization or as an individual?

Honestly, even if I try I don't think I can come up with a better sentence than this one from the official Microsoft SharePoint site:

"… Microsoft Office SharePoint Server 2007 provides a single, integrated location where employees can efficiently collaborate with team members, find organizational resources, search for experts and corporate information, manage content and workflow, and leverage business insight to make better-informed decisions."

--- Pasted from <>---

SharePoint is an extension to the cloud (Internet) of all of the Office Family of products. In fact SharePoint is part of the Microsoft Office Group. If you or your organization are using any of the Microsoft Office products (Word, PowerPoint, Excel, etc) then you are half the way into becoming a great SharePoint user and take full advantage of its offerings. Although SharePoint clearly targets more businesses than individuals, the fact that most of us work for some corporation means that we're very likely to at one point or another face the SharePoint solution of your workplace. And trust me, I'll make your live so much pleasant… SharePoint will be there when:

  • You want to cut dramatically the use of paper and ink in your organization.
  • You want to improve the performance of your employees and make them work better and more organized between them.
  • You need to collaborate with a team member in writing on the same document simultaneously.
  • You want to request a day off without having to confront the boss.
  • You want people to request a day off without coming to your office or spending a fortune in paper and ink. Also want to be able to notify the requestor of your decision about his request.
  • You are a manager and you want your team to work under your schedule and not the other way around.
  • You want to expose your professional profile in the company's SharePoint to find opportunities in other departments and move up within the organization. Get discovered.
  • You want to make a small correction to a published document and will be able to make the change and make it available immediately online with one click. No downloading and re-uploading, no emailing required.
  • You want to see how a particular spread sheet or document looked like last month without disturbing the IT department to pull it off the archive.
  • You want to broadcast the meetings calendar to all the Outlook account in your department with a click of a button.
  • You want to automatically get notified when somebody completes a sale, or gets a new bid, or renews a contract and want to see at a glance the ongoing financial health of your company with real-time data.
  • You want to have a fun home page with your favorite color and alternating pictures of your family.
  • You want to access all corporate data securely from the internet.
  • You want to monitor each department of your organization and ensure they are meeting the new goals with key performance indicators.
  • You want to collect and automate the employee contact info by having forms your employees can fill in and submit from any web browser.
  • And much, much more… :)


I hope you after reading this article you have a better understanding about what SharePoint is, how it differs and stands out over traditional web site design as well as the immediate benefits that SharePoint brings to organizations and individuals and a general feel for some of the coolest features SharePoint offers. I think in general SharePoint is a great solution, ever evolving (SharePoint 2010 is Beta already). I'll try to cover more on SharePoint in future posts.

Thanks for reading!

1 Comment