[: GaB :]

Are you part of the web security problem? An indepth review of the current most common attack vectors is a must-read for every web developer.

It looks like two-third of the attacks are based on three vectors:

1. SQL injection (25%)

$id="1;DROP TABLE users"; mysql_query("SELECT * FROM bars WHERE id=".$id); It is deeply shocking how many "developers" still don't get the message not to execute SQL commands forged from user input. Or at least, why are they still employed? This attack would be the most simple to prevent. You just always have to *escape* strings which are parameters of the sql query coming in as request parameters. If in doubt, what do I mean by that, simply escape *all* parameters of a query. Or better use queries parameterized as "SELECT ... WHERE id=? AND type=?"-s, your language must have a way to pass the values safely afterwards.
But stop, why in the world are these guys still writing any SQL queries in the first place?! Because script kiddies don't know what a persistence framework is. Stop handcrafting CRUD DAOs.

2. Cross-site scripting a.k.a. XSS (17%)

Rule of thumb: always check. If you use any output mechanism or view, check whether it escapes or not. If not, it is *your job* to do so! (Error messages printing also the invalid value are the simplest to overlook.)

* <c:out value="${id}" /> escapes by default.

* ${id} never escape by default. This is one of the most pithiest design decision in JSTL/EL. It is insecure by default. But of course you have the option to turn on security. Thank you very much. I understand the need for backward compatibility, but this is the kind of design problems which can be solved. Why not add an option to change the default behavior, and add fn:unEscapeXml() ?

<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
${fn:escapeXml(id)}

Plain EL expressions to produce output is pure evil.

* The output tags of your framework of choice is the most important to test. Never assume you already know it. In Spring 2.0 escaping in the form:input and form:errors tags were optional and off by default. In 2.5, it was switched to on by default in the documentation. But form:errors tag continued to print out unescaped output. In 3.0 everything seems to be fine by default in both.

Just to improve your chances always add this to your root context:

<context-param>
    <param-name>defaultHtmlEscape</param-name>
    <param-value>true</param-value>
</context-param>

3. Authentication and authorization (14%)

I guess mostly this happens by plain simply ignoring security logic. Most likely to happen when refactoring and ignoring to adopt security logic to the new business logic or domain structure. Those three should be independent by design. AOP or a security framework is a good candidate for separating the security concerns.
If you are not in control of the server side issues, use discovery tools like PhpSecInfo.

++1 Cross site request forgery a.k.a. CSRF and XSRF

Only 2% of the identified attacks fall into this category. But I also saw a lot of plain simply wrong attempts to fix this issue. This also shows how non-trivial it is for the average programmer to safeguard against this kind of attacks. It feels like many sites are vulnerable but not exploited yet.
To check the ingenuity of requests, first one must ensure, that GET requests are never changing state of the domain. (Trivial but not for everyone.)
Second, to always check POST requests' referer header values: they must match yours. This is sufficient for protection against XSRF, but has limitations.
Mostly suggested are tokens, a hidden field in every POST with a random variable identifying genuine requests (e.g. hash of the SESSIONID). The problem is, that every browser has a way to hack around it. You have to generate a new random token for each request to be used to fully safeguard yourself.
Alternatively you can change URLs dynamically (the token becomes part of the URL): for example you can use Spring's @PathVariable annotation bound to a @RequestParam("/action/{nextToken}").

The difference between the php_admin_flag and the php_admin_value apache directives are that the first one is for boolean values and the latter one for anything else.

Example:
php_admin_flag        safe_mode           Off
php_admin_flag        safe_mode_gid    On
php_admin_value     open_basedir       /tmp:/sites/thang.tld

Back again to the webmail issue. Finally I found an open-source solution written in Perl.

No wonder I couldn't find a webmail that is able to manage forward options and passwords and is written in PHP. It's hard to deal with the user and permission management of PHP. A PHP environment either allows far too much access to the system it is running on or it is so heavily restricted even the most light-weight CMS is unusable. Of course it is possible to finetune open_basedir, safe_mode and a lot of other parameters of PHP, but just a few webhosting companies take the time and money to configure their services properly.

Perl OpenWeb is different. As it runs as a local script, it is able to access services with the proper privileges. It can change password, directly manage quotas, and even has a Java SSH applet bulit-in. Here are some features:

• Auto Login
• Multiple Languages/Multiple Charsets
• Strong MIME Message CapabilityFull Content Search
• Draft Folder Support
• Confirm Reading Support
• Spelling Check Support
• vCard compliant Addressbook
• POP3 Support
• Mail Filter Support
• AntiSpam Support through SpamAssassin (http://www.spamassassin.org)
• AntiVirus Support through ClamAV (http://www.clamav.net)
• Calendar with Reminder/Notification Support
• Webdisk Support
• HTTP Compression
• Fast Folder Access
• Efficient Message Movement
• Smaller Memory Footprint
• Graceful File Lock
• Various Authentication Modules
• PAM support
• Remote SMTP Relaying
• Virtual Hosting
• User Alias
• Pure Virtual User Support
• Per User Capability Configuration
• Persistent Running through SpeedyCGI

It supports any kind of database where you can specify your own SQL queries to handle authentication and password change.

To mention some disadvantages: the documentation would require a little cleanup. There is no single install howto, you have to read a couple of readmes, with a lot of redundancy. But after all you get a clean view of the software and it's feature are worth of understanding it's inner working. And yeah, as it is written in perl, it requires some modules and privileges what you won't get to the price of PHP webhosting.

http://openwebmail.org/