Wednesday, April 29, 2009, 5:12:00 PM
A number of people have run into issues with PCI compliance due to a security bulletin that was put out on Web Connection some time ago. The issues in the bulletin have since been addressed in recent versions, but I thought I take the time to reiterate the importance of making sure that your Web Connection applications are secure.
The Security Bulletin Issues
Let’s start by addressing the Security Bulletin issues first.
This cross site scripting issue has been fixed some time ago. I don’t remember the actual version number but the fix has been in recent versions of Web Connection. If you’re running version 5.x you can upgrade to the latest version, older versions can manually do a quick fix for this particular issue.
The issue is that on a failure request that tries to access a page Web Connection by default returns an error page that looks something like these:
The issue here is that West Wind Web Connection echo’s back the query string value it finds and in earlier versions this value was not properly sanitized. If not sanitized it’s possible to embed script into the URL and that script can execute in the browser.
As mentioned this has been fixed in current versions, so if you create a new project all’s well. You should see something like this:
This properly encodes the offending input and simply echo’s it back. In the actual HTML the text is HtmlEncoded and looks like this:
..type of Request: WWDEMO<SCRIPT>ALERT('DANGER WILL ROBINSON');</SCRIPT>
and so is safe.
However even if you are running the latest version but you have a main application class (ie. MyAppMain.prg) you may still have this vulnerability in place! It’s an easy fix, but you still have to fix it. Find the Process() method in the MyAppMain.prg and the Process method. In it towards the bottom find the OTHERWISE clause and make sure the call the StandardPage() includes EncodeHtml() for encoding the lcParameter:
*** Error - No handler available. Create custom
"The server is not setup to handle this type of Request: "+ EncodeHtml(lcParameter))
This basically sanitizes the parameter and ensures it is turned into an HTML string rather than embedded as raw HTML text that can contain script.
There are several other places inside of West Wind Web Connection where similar routing errors echo back content but those locations are internal and have been fixed. If you have a pre-5.0 version of West Wind Web Connection you’ll want to look in wwProcess::RouteRequest (or wwProcess::Process() in older versions).
Note that although this fixes the West Wind Web Connection internal messages, there are still a few other places where this can be problematic, especially in your own code. Specifically some of the West Wind Web Connection demos that strive to show you some of the information available can potentially be used for XSS attacks as well, so on production sites it’s a good idea to remove the wwDemo project from the installation.
This also applies to your own code – anytime you take input from a query string there’s potential that the URL will be hacked and you have to be careful when echo that value back in the user interface. The universal and often tedious remedy for this is to use EncodeHtml() around text displayed to ensure that angle brackets (< >) are properly Html encoded and aren’t interpreted as html and script.
If you are going through PCI compliance especially, make sure you review your application and look for places where user input is DIRECTLY echo’d back. You’d be surprised how many places there actually are in your applications where this can occur.
XSS attacks are tricky because they don’t seem very dangerous and typically they aren’t unless you can force somebody to click on a corrupt link that includes script. The most common target of XSS attacks is to give up cookie and possibly confidential information (the latter is difficult to do, the former quite easy). It takes quite a bit of effort to ensure that all input you receive is sanitized, but that is a responsibility of your application. It has to decide what should be encoded and what shouldn’t.
It pays to think about this while you’re actually developing your applications and anticipate vulnerabilities. It’s much easier to fix at the time of creation rather than after the fact!
By default West Wind Web Connection ships with Administration access wide open, not requiring any security. Specifically this refers to the security setup in wc.ini which determines which account has access to the administration functions. The AdminAccount key in wc.ini controls this and by default it is shipped blank. I have now made a change in the default as of version 5.42 but I suspect this will cause more problems than it solves as people trying out the product for the first time are likely to be struggling with figuring out which login to use.
Anyway, Security is important and any site that goes live should have security enabled. To do so open up wc.ini and set the AdminAccount key:
;*** Account for Admin tasks REQUIRED FOR ADMIN TASKS
;*** NT User Account - The specified user must log in
;*** Any - Any logged in user
;*** - Blank - no Authentication
You can use any valid Windows user account here or ANY to allow only non-anonymous access to the admin interface. The new default for new projects starting with Version 5.42 is ANY.
Note that this key controls access to the wc.dll admin functions as well as access to the ~wwMaint functions that are the FoxPro based administration links (show and clear logs, reindex system files etc.). These wwMaint process class also reads the security settings from wc.ini, although in wwMaint it’s possible to override the security behavior if you choose. The DLL access is limited to OS Authentication.
Note that several people over the years have mentioned that they thought just removing the Admin page will protect them from anybody finding the wc.dll admin links. THIS IS NOT THE CASE. Anybody that knows the URLs can access the admin links so it is vital that every application you deploy has security set on the administration links in wc.ini!!!
Other Security Items you should implement
First off the help file has a fair bit on Security configuration of West Wind Web Connection here:
and more to the point:
You can read more detail there but I’ll highlight a couple of additional things that you’ll want to do:
- Set ACL Permissions on Directories
You’ll want to lock down any sensitive or administration directories by removing anonymous access in these folders of your application. Remove the IUSR_ account from these directories. Strip all directory access to the lowest access you really need – for West Wind Web Connection apps this typically means Read/Execute access. Remember West Wind Web Connection runs under either the active account when running in file mode or under the configured DCOM account. The only user that needs rights typically is just that account. So if you need to write files in the Web folder because you’re auto-generating images or reports for later pickup for example, you only need write access for the account West Wind Web Connection runs under.
- Section your Site into Open and Locked Down Areas
On too many occasions I’ve reviewed sites to find that Administrative features are intermixed with application level functionality and usually that’s a really bad idea. If you have administrative tasks that require elevated rights and access to sensitive features, make sure you isolate those features into separate folders and possibly separate West Wind Web Connection Process classes. This makes it much easier to administer security on these areas. Folders can be locked down with OS security and a single process class can handle security all in one place (like wwProcess::OnProcessInit or OnAuthenticate). This makes the security features isolated and maintainable in one or two places.
- Use ScriptMaps – don’t use wc.dll
This isn’t really a security item per se, but it affects site administration. By using script maps you’re not tying yourself to a specific implementation and you get much more control over links and how links are fired. Further script maps allow treating scriptmapped pages just like any other page and respect relative paths, something that wc.dll directly doesn’t do. ScriptMaps can also prevent direct access to admin functionality which further limits the security footprint of your . Additionally IIS 7 doesn’t allow execution of .dll files out of a bin directory any longer (unless you override the filter rule) and direct access to .DLL links requires additional rights configuration in IIS. ScriptMaps provide a safer way to access requests. If you are still calling wc.dll directly consider moving to script maps.
Security in Web application is a serious issue and it isn’t easy. Security is a process not something that you can easily slap on after the fact – thought needs to be given to security issues right from the start.