Many software choices are available to professionals who need to run applications in their business. Some of these will be delivered by conventional vendors who have full control over the product and its development. However, over the past decade many Open Source applications have emerged as viable alternatives, developed using an open process by volunteers from many different companies.

Speaking from his experience as an Open Source Software developer, Sander will compare some security aspects of Open Source and Closed Source software, likely debunking some myths along the way. We will examine the security vulnerability mitigation process used by the Apache Software Foundation and discuss how an open development process can provide enhanced security.

See the meeting page for details. An RSVP link is at the bottom of the page.

Oh man an experienced sys admin told me to do it that way.
Please tell me what is wrong in this and where is this documented on Apache
docs.
I want to read.

Here is my response reproduced: read on.

The Apache HTTP Server needs read access to its configuration files and the files it serves. In and of itself, the server does not need write access anywhere on the system: even its log files are opened for write when the server is still root, and the open file descriptors passed to the child processes which change their user id to the lesser privileged user.

Read access only. The web server user should not own, or be able to write to, its configuration files or content.

Content, other than CGI scripts, generally does not need Execute permissions. Even PHP files that are interpreted by the server do not need to be Executable.

Certain applications, especially publishing platforms and Content Management Systems that you manage and populate through the web server itself using a browser, require that certain directories on the system be made writable by the web server user. You can do this by changing the owner of the directory to that user (usually www but ymmv), or by making the directory group-writable and changing the group to the group as which Apache runs.

Making directories writable by the web server should be done only with care and consideration. The usual threat model is that someone manages to upload (for instance) a PHP script of their own making into the document root, and simply executes that by accessing it through a browser. Now someone is executing code on your machine. Google for ‘r57′ for an example of what such code can do.

If a web app needs writable directories, it’s often better to have those outside the DocumentRoot: that way the uploads can’t be accessed from the outside through a direct URL. Some applications (WordPress for instance) support this, others do not.

In many cases, writable directories are not strictly necessary even though the web app might like them: rather than upload plugins (which contain code that gets executed or interpreted, yech!) through the web browser, upload them through ssh and manually unpack them on the server. The CMS Joomla! likes to write its configuration file to the Document Root on initial install (which promptly becomes a popular attack target) but if it can’t write to the Document Root, it will output the config to the browser to the user can manually upload it.

The Apache Documentation will merely tell you to make the server installation root-owned. The HTTP Server Documentation does not cover third party applications like WordPress or Joomla!, so it will not discuss their need to have some directories writable. I hope the above makes the picture a little more complete.

I am not sufficiently familiar with the cryptography in use for the EMV protocol, but my first thought is that astute observation by POS personnel should provide substantial defense against this entire class of attack: if someone shows up at your cash register with an EMV card wired to his backpack, something fishy is probably afoot.

My other thought has to do with the notion that banks might attempt to shift the responsibility for fraudulent Chip-and-PIN transaction to the consumer. “Since EMV is so secure,” the reasoning goes, “the PIN authorization is proof positive that the transaction is valid.” Except it has now been shown that PIN authorization can be spoofed.

Security is not black and white: it does not make fraud impossible, but makes it harder and more expensive to commit fraud. The protection level provided by a security feature should be commensurate to the value of the transaction it protects. Too high a protection level is likely to be more cumbersome, or more expensive, than the transaction in question justifies.

I went in through the link above, gave up my e-mail, phone number and name of my first born, and downloaded the report. This will probably land me another copy of every marketing e-mail Breach sends out (guess how I learned of this report?), and a phone call from some poor guy in a cube who has to make 75 phone calls a day for a living. Oops, guess I put down a fax number. Sorry dude, hope your headset isn’t too loud.

Anyway, after you go though the lead generation form you land here and can follow a direct link to the PDF. This is fairly standard practice, but from a security company I would expect that they would make some more effort to not inadvertedly expose the goods.

I will give this report a read, and probably discuss it in my upcoming talk at ApacheCon US 2009. Oh, they just extended the early bird registration deadline… without changing their own website to tell you about it. Register now and experience the mayhem.

I also included links to some interesting articles and organizations. Most of these were visited early November 2008:

• The Apache HTTP Server Security Report
• The Center for Internet Security who publish benchmarks for web server and operating system security
• The Open Web Application Security Foundation concentrates on developing secure web application code
• The Web Application Security Consortium
• The National Institute for Standards and Technology (NIST) published a checklist for securing internet-facing web servers

Man In The Middle is defeated by context. – Bruce Schneier

As has been widely discussed, Firefox 3.0 is a little over-zealous when it encounters an unknown certificate on an SSL website. Where previous versions would just warn the user about the observed irregularities, the new version requires that the user add an exception for every certificate that has an unknown certification chain, is expired or for which the hostname does not match the information in the certificate.

Adding an exception takes four clicks, most met with a stern warning that will deter anyone but the most determined user. Folks who use self-signed certificates as a matter of habit are howling, because they have to tediously make exceptions for all of them. This Firefox features seems over the top, but is it? It is not. The validity of the certificate at the other end of the connection plays a critical role in establishing the trust relationship between endpoints. An invalid or unverified certificate gives no assurance whatsoever about the identity with whom we’re handshaking: it could be the true endpoint or a Man-in-the-Middle entity that is passing themselves off as the endpoint.

The difference between running the Exception gauntlet and a trusted identity should not be taken lightly, and while public-key cryptography in the context of identifying endpoints is still too hard to use for the general public, Firefox’ reluctance to accept untrusted certificates is the right thing to do.

Folks who want to use self-signed certificates have a very attractive alternative: with a couple of clicks, they can add the certificate to the Firefox Certificate Store by either importing the server certificate, or pulling it right from the server by pro-actively adding an Exception. Just use Preferences -> Advanced -> Certificates. Beyond a certain number of certificates, though, it may be easier to set up your own CA, and import its certificate. That allows you to set up servers with certificates that are automatically trusted by your client(s).

Laments that certificates are expensive are out of place: $30 a year buys you a certificate that is trusted by a lot of browsers. Additionally, PKI is the ultimate do-it-yourself environment: you are perfectly welcome to set up your own and determine the level of trust you allot it.

• Training: Web Application Security Bootcamp by Christian Wenz
• Thursday, 9AM: Hardening Enterprise Apache Installations Against Attacks by yours truly
• Thursday, 10AM: Web Intrusion Detection with ModSecurity by Ivan Ristic
• Thursday, 2PM: (In)secure Ajax and Web 2.0 Web Sites by Christian Wenz
• Thursday, 3PM: Geronimo Security, now and in the future by David Jencks
• Thursday, 4:30PM: Securing Apache Tomcat for your Environment by Mark Thomas
• Thursday, 5:30PM: Securing Communications with your Apache HTTP Server by Lars Eilebrecht

Besides the training (which happened on Monday), this means that you can pretty much stay in the same room all Thursday and catch all the Security-related talks. In addition, of course, this track will be streamed live for a modest fee, so you can watch from the comfort of your own office if you find yourself unable to make it to ApacheCon this year.

Why is it that our websites almost universally use a data access language whose statements can be completely subverted by the parameters fed into the queries? The problem is that web applications compose queries out of text strings concatenated with the input fed in by the client. The result is a SQL query that is sent, as a text string, to the SQL server and executed. Any input from the client that constitutes valid SQL fragment will be incorporated into the query, and can be used to wreak havoc with the database just like little Bobby Tables just did.

The main line of defense against this attack is to validate anything the client sends to a web application, and to strip out any SQL fragments that may be in there. This is of course an arms race: any validation attempt is met with new attempt to defeat the validation, ad infinitum. What we need is a new paradigm for querying databases from web applications: query parameters should never be treated as part of the query definition, but become opaque entities that are passed to the database engine as-is. The result of the above should be noting else than Bobby bringing home a report card that says “Robert'); DROP TABLE Students;--” across the top.

Oh, and what business has the web application dropping tables anyway? Why does its user have that privilege?

No guarantees that using SSL will make me post more often. Life has been busy.

I will be presenting one session at the conference: Hardening Enterprise Apache Installations Against Attacks will discuss security issues with the Apache Web Server and how the developer team reacts to issues as they are found. We’ll also talk about protecting applications that are served by the Apache server and may be the target of attacks that do not subvert the web server itself, but the code behind it.

The first time I did this talk, at AacheCon EU 2008, I ran out of time. There’s so much to talk about! The feedback forms submitted by the attendees did, however, identify some spots I can tighten up, so I’m looking forward to present a new, updated version of the talk this fall.

Hope to see you, first week of November, in New Orleans!