Ask Slashdot: Writing Hardened Web Applications?

rhartness writes "I am a long time Software Engineer, however, almost all of my work has been developing server-side, intranet applications or applications for the Windows desktop environment. With that said, I have recently come up with an idea for a new website which would require extremely high levels of security (i.e. I need to be sure that my servers are as 100% rock-solid, unhackable as possible.) I am an experienced developer, and I have a general understanding of web security; however, I am clueless of what is requires to create a web server that is as secure as, say, a banking account management system. Can the Slashdot community recommend good websites, books, or any other resources that thoroughly discuss the topic of setting up a small web server or network for hosting a site that is as absolutely secure as possible?"

Comments

Re:If you don't know, you can't do it

[Anonymous Coward]

I guess we'll just halt all human endeavor, since each of us doesn't know how to do every possible thing.

Moron.

Web Applications aren't different

[Elgonn]

I've seen many a question or thought like this and I don't understand the underlying wonderment. Web applications aren't different than any other networked applications. You just have a larger selection of clients that could be communicating with you. But you'd never trust ANY client would you?

Re:Web Applications aren't different

[rsilvergun]

Aren't web apps very different? Inside my Intranet I can make certain assumptions that I can't on the Web. If those assumptions prove false, it's because another layer above me isn't doing it's job. You might balk at this, but the fact is that as programmers we're constantly relying on some layer above us; whether it's network (TCP/IP, SSL, TSL), software (the OS, the API) or hardware (is the Memory on this board bad?).

Re:Web Applications aren't different

[tysonedwards]

Exactly, the idea should be that you should assume that every piece of data that you are receiving is likely malicious, so as such you should sanitize every variable, never execute *anything* sent to you, mandate bidirectional encryption in which you verify certificates at both sides, and kill the session if a single out-of-order packet is received.

As well, block *every* port except the one that you intend to use within your application, and monitor all traffic to detect anyone *attempting* to connect over any other port, and immediately greylist their IP Address for an hour. If they repeatedly do it, than blacklist them permanently.

As well, requesting a non-existent resource should be treated just as trying to SSH in to your box as root!

Anyone who legitimately runs into your security protections would need to call to get their account reinstated.

You should also ensure that any functions that will only be *reading* data do not have privileges to *write* data under any circumstances.

Only writing functions should be capable of writing to your data stores / databases.

Any malformed entries stored within your database should be immediately flagged as "bad data" and *not* presented back to the user. The record should simply be gone. Any one user who has more than 3 pieces of "bad data" associated with their account should be immediately blocked pending review.

The best course of action with regards to designing any hardened applications is to assume that any data coming from your own, non-internet accessible servers is suspect and then you will do well in limiting risk.

Re:Web Applications aren't different

[b4dc0d3r]

Sounds like you're making bad assumptions. One unexpected breach and your network is no longer secure. On a secure network, you still close off all of the ports except the ones you use. You don't make assumptions that something is safe, you add IP filtering and passwords.

Web apps are exactly the same as any other intranet app, and should be just as secure. The only difference is, you also have a web server and a framework adding potential bugs and holes. And then your code most likely has to protect against common browser-based attacks and handle user authentication/authorization on a stateless connection.

Don't trust anything on any network, or you'll end up like Sony. Breach after breach.

Re:Web Applications aren't different

[nahdude812]

You fail to actually address any of the technologies he mentioned as a layer above. You're talking about closing ports and other pretty standard bland basic intro-level security. Sure, there's overlap, but what he's saying is that a lot of common Internet problems are reliably and intelligently pre-solved for you if you control enough of the technology stack.

I'll pick his example of TLS since that's a good example of the sort of technology stack you can rely on in an intranet application which is prohibitive to implement in an Internet application.

If your web server has validated a TLS certificate, unless your signing authority has been compromised (and for internal purposes, that's owned by your own company's security team), you can trust the subject of the TLS cert. It is not only considered safe to assume that TLS is valid, it's widely regarded as one of the most secure possible means of authentication you can have since it includes endpoint verification on both ends. It's excellent practice, but if your CA is compromised it falls apart. Of course you're probably also relying on other proven technologies like LDAP for identification, but if someone ends up with write access to parts of LDAP they shouldn't have, this falls apart too.

In internal applications you can make these sorts of assumption that aren't really available on the public Internet since you don't control enough of the technology stack outside your own network to do so without substantial inconvenience for your customers. That doesn't make you a bad developer. In fact the opposite is likely true. If you're building an intranet web application and you think you can do a better job of managing user credentials than LDAP or a better job of securing communications than TLS, you're deluding yourself and very likely introducing security bugs into your application.

Re:Web Applications aren't different

[Thiez]

> and kill the session if a single out-of-order packet is received.

Isn't that a relatively common and normal occurrence with TCP/IP? I fail to see how this would help as the packets will be presented in the right order to the application anyway.

Re:Web Applications aren't different

[b4dc0d3r]

a lot of common Internet problems are reliably and intelligently pre-solved for you if you control enough of the technology stack.

Another bad assumption, that you control enough of the technology stack. I did address the technologies a layer above. You can't control the IP implementation, nor the TLS, nor LDAP, nor anything else outside of what your framework allows you to control.

Therefore, you have to distrust everything. Assume your LDAP is compromised, that TLS is broken, that your framework and web server and host OS are all broken. Write as defensively as possible.

This isn't about just writing an application, there is OS level hardening, web server hardening, framework hardening, and more. You can't assume it's all in place and just write the application. Especially if you are "clueless of what is requires to create a web server that is as secure as, say, a banking account management system."

That is the (one of) the reason(s) Sony got hacked repeatedly within a few weeks. Don't assume anything. The web is hostile, everyone is an enemy, and no matter what your assumptions, unless you assume that everyone is an enemy, you are going to be wrong. Just once out of a million page views, or a trillion, or a trillion squared, once is all it takes.

Re:Web Applications aren't different

[TheLink]

and monitor all traffic to detect anyone *attempting* to connect over any other port, and immediately greylist their IP Address for an hour. If they repeatedly do it, than blacklist them permanently.

From what I see in real-world firewall logs, there are often tons of IPs trying to connect to your nonlistening ports. And those can be from dynamic IP users. Blacklisting these permanently would cause more problems and not really help much (assuming your system is hardened and has upstream DoS/DDoS protections in place).

and kill the session if a single out-of-order packet is received.

If you're worried about that sort of thing, you should solve it by using TLS/HTTPS (correctly ;) ) rather than killing sessions just because an out-of-order packet is received. If the attacker already has the ability to pwn a user's TLS/HTTPS connections, the attacker has no need to inject out-of-order packets to pwn that user.

If you're that paranoid what you could do is set up "honey data" and "honey rows" in database tables. For example, you could create customer records of nonexistent people/items who/that don't appear anywhere else in the world. If those data/records are ever accessed, it means something has gone wrong. And if that data ever appears "outside" (internet or elsewhere), it may mean something has gone very very wrong...

Another way for attackers to access the data would be via the backups and the systems that do backups. So even if your web apps and servers are super-hardened, it may not matter if the attacker can get the data via the backups.

internet explorer

[Anonymous Coward]

For some reason, every bank we deal with (for large business types) is internet explorer only. I guess you'll have to start there.

EULA baby!

[cultiv8]

Why harden your web app when you can just write in your EULA that end users can't sue you? Profit!

Start with the W3 guide to secure CGI programming

[TheEmperorOfSlashdot]

http://www.w3.org/Security/faq/wwwsf4.html

Once you understand the things they recommend and WHY they recommend them, you won't need to ask this question anymore.

Filter EVERY input right at the start.

[unity100]

And do blanket filtering. never trust input. always filter to extreme, as long as you can get away with it. as much as you can get away with it.

Re:Filter EVERY input right at the start.

[Alex Belits]

The only problem is, there ARE people named Bobby Tables. "Filtering" is the wrong approach, the program must be able to handle any input in a safe manner, no matter how scary it looks like.

And, minimize damage.

[unity100]

However hard you write your web app, if its running anything important, it WILL get hacked. there's nothing on this planet that cannot get hacked if it is a software. even hardware can get hacked if it is running on even read-only software. so, assume it will get hacked, and design so that you will minimize the damage when the app is hacked.

Get IIS 4

[Billly Gates]

And use VBScript with activeX controls mixed with sql server 6.0 and make sure the clients all have to use IE 6.

Throw a little ASP, not asp.net or anything bloated that checks the sql agaisnt injections and you will have one rock solid platform that nothing will get hacked or get intercepted.Just ask any MCSE to secure it and you are good to go

OWASP.org

[LouTheTroll]

Be sure to checkout out all of the fine resources at http://www.owasp.org./ It's the Open Web Application Security Project. All materials, training, libraries, and content are free. There are numerous local chapters also so be sure to search for one in your local area.

Be paranoid (trustno1)

[gman003]

Trust no inputs. Check your inputs. Validate cookies. Validate parameters. Validate your validation. Encrypt whatever you can, whenever you can.

SQL injection is the most common vulnerability. Learn how to make it impossible with prepared statements.

If possible, hire some white-hat hackers to try to break into the site, and see if they find anything.

Above all, trust nothing.

Re:Be paranoid (trustno1)

[KevMar]

Above all, trust nothing.

That's the most important rule of thumb. Don't even trust your own client code.

Make definite security boundaries. Draw a circle, label it data. Draw a circle around that circle, label it prepared statements. Keep drawing circle adding layers for each security boundary so you have something like this.

Data-> prepared statements -> firewall -> web server -> business logic -> user state management -> browser -> client side code -> user input

Each layer needs to validate everything. Let each layer assume that the protected layer in front of it is missing. It just does not exists. One common issue is having only the client side code validate the user input. I love to modify client side code to bypass validation just to see what breaks. If its HTML, there are so many ways to do that.

not only prevent, but also mitigate

[OleMoudi]

While one can arguably say everything can be hacked (unless air-gapped), in certain scenarios you can at least mitigate the impact of a breach to make it almost irrelevant.

Easiest example is password storing. Some SQLi may get through and provide someone with a dump of your user passwords, but if you follow up to date recommended security practices, the data will be nearly useless.

Beind said that, just by reading the Web Application Hacker's Handbook and following all of its recommendations you will have a pretty secured app.

Layers

[jbolden]

A few things;

1) Multiple layers. Consider your application and the entire framework it exists in. Assume that each part is completely under the control of a hostile. Now design the system so that the hostile still can't do much harm. So for example start with the webserver assume it were hostile, how are you protecting the data? Go through the entire architecture this way and make sure you can contain any type of part under hostile control even if it went undetected.

2) You probably want to be using capabilities not permissions i.e. X has the permission to do Y to Z, not X has the permission to do Y. That takes a ton of time to setup, and it is as much a jump in security as going from no password to passwords.

3) You want to use languages, servers, software that are security aware and designed. So for an obvious example you want to use web frameworks that taint check everything as a matter of course. You want a database that does the same thing (remember multiple layers).

4) You are going to want a full security implementation. A fragmented network, the server in a DMZ with monitoring behind a firewall. You are going to want intrusion detection and vulnerability assessment.

5) If you are really serious, hire a white hat team to audit you and do multiple cycles.

And if your boss is serious I'd be happy to start discussing this professionally.

Re:Easy answer

[msobkow]

Well, then he's picking a poor example of web security given the banking industry's track record on break-ins and id theft.

If you want to see guidelines about what you have to provide for a secure system, check out Saskatchewan Health Information Protection Act for one region's take on what data protection means.

As to the technology of how to deploy that, there are no easy answers and checklist standards. New attack vectors and design oversights come out all the time, so web security is an ongoing battle, not something you just design for and "finish".

Learn to break them

[DarwinSurvivor]

Software engineering is fairly similar to structural engineering. Just as an architect does not truly understand how to create an indestructible building without first learning how buildings are destroyed, you can't possibly hope to create a secure software system without understanding how software is broken.

If you are serious about securing your software (without having a security expert on hand), you need to spend some time *breaking* software. http://www.hackthissite.org/ has some fairly good tutorials, but you're also going to need to learn about buffer overruns, binary magic (such as never-ending zip files and over-sized jpegs), sql injection, malformed packets, firewalling, fail2ban, encryption (certificates at the very least), intranet isolation, air-gapping, client-securing, hardware securing (disabling USB ports), etc.

Basically, there is a reason security experts spend so much time in school and charge so much per hour. If this project is already in the blue-print stage and has a deadline, you should be looking to hire a security expert at the planning stage and at least a few audit stages along the lines. If this is more of a pet-project, it could be a very good way to get yourself motivated to learn these subjects.

You give banks too much credit

[Tony Isaac]

Citibank had a security hole that let people just change the credit card number in the URL! http://yro.slashdot.org/story/11/06/26/1334209/citi-hackers-got-away-with-27-million. AND they passed security audits!

I can also speak from personal experience. A company I worked for had to pass a security audit in order to do business with the City of Houston government. It was a joke. We programmers all knew of glaring security holes, but the audit missed everything, and we passed with flying colors.

The moral of the story? Use common sense. Do the things that you know make a site more secure. Don't store plain-text passwords. Use stored procedures. Use SSL. Use the latest development tools. Somebody will still find a way around your security controls. But to keep your customers happy, get a security audit done. That will give them the peace of mind they want, and you the cover you need.

Nobody has created real rock-solid security--physical or digital--without spending truckloads of money.

Re:If you don't know, you can't do it

[FormOfActionBanana]

That's untrue. You can assume the worst and protect your application by following secure coding checklists, code reviews and static analysis. You don't need some sort of reformed hacker on your team in order to be effective.

Re:Start with the W3 guide to secure CGI programmi

[Chuck Chunder]

you won't need to ask this question anymore.

Pretty bad advice. Unfortunately this is an area where you will continually need to keep asking the question. While there are certainly basics that should be covered there are also subtleties and interactions and new exploits in software you will depend on.

The OWASP top 10 is a pretty good starting point.

Re:If you don't know, you can't do it

[stevenfuzz]

Explain this to Sony and Citybank.

Re:If you don't know, you can't do it

[Vellmont]

That's untrue. You can assume the worst and protect your application by following secure coding checklists, code reviews and static analysis. You don't need some sort of reformed hacker on your team in order to be effective.

The OP never claimed you needed a reformed hacker to be effective, merely that you need to think like an attacker. That's certainly not following a bunch of check lists, static analysis, some code review, and calling it a day. Those techniques are helpful, but they're only a piece of the puzzle (though I'd be willing to argue that a check list mentality is likely counter-productive).

To create effective security you need to understand the attack vectors, and what you're securing. Code is only part of security. Your own code can be completely secure, but you can get owned by a 3rd party library or framework. All that crap can be secure, but you get owned by someone tricking a secretary into opening up an Excel spreadsheet with a zero-day Flash exploit. Security is an entire discipline, and it shouldn't be swept away into a few simple rules and procedures to follow.

Can you trust a network because it's intermal?

[gwolf]

Most attacks come from trusted machines, either from people wanting to use their rightful access level to get more data than what they should (or modify data they should not be allowed to), or by bots crafted to infect internal users' workstations and rob their credentials. No, you shoul not trust them just because they are internal anymore than what you should trust me.

Re:What the Fuck?!

[MrMarket]

Thank you. This thread is a pos if you are interested in learning the topic. This is why people hate nerds.

Re:Start with the W3 guide to secure CGI programmi

[nahdude812]

Wow, I can't believe this is still around. It's pretty dated. Let me demonstrate:

Q3: Are compiled languages such as C safer than interpreted languages like Perl and shell scripts?

The answer is "yes", but with many qualifications and explanations.

Really? C is a safer web language than Perl? Buffer overflows and all? Their example that you might accidentally be editing a file (in production?) in Emacs and leave a backup file sitting around that someone can request, and therefore have access to its source code is so weak it's pathetic. Isn't every major modern web server already configured to refuse to serve files whose mime type it does not recognize from the file extension? "Foo.cgi~" won't be downloadable because the web server doesn't understand what a ".cgi~" file is. Never mind that this example assumes that you're engaging in the egregious sin of editing a file on a production system.

If it's not editing directly in a production system, you almost certainly have a .gitignore (or .cvsignore or .svnignore or whatever) set up to ignore backup files, so it'll never go through your build system or become part of your deployed package anyway. And STILL if you're relying on the obscurity of your source code as a security measure, you're doing something wrong. It doesn't hurt to keep the source secret, but by no means should you be compromiseable because someone was able to get a peek at one of your source files. If someone wants your source code badly enough, they just need to pay off one of your engineers and they get the entire stack source, maybe even revision history. Corporate espionage is all but impossible to track down the perpetrator unless he's very stupid, and it leaves a lot less evidence behind than traditional brute force attempts (like guessing script file names and looking for backup copies somehow left around in production).

Re:If you don't know, you can't do it

[TubeSteak]

Your own code can be completely secure, but you can get owned by a 3rd party library or framework.

Or by not updating the OS your server is running.
There's no point in spending time, effort, and money coding an incredibly secure website backend if you're running it on an OS that's susceptible to a 6-month old remote exploit.

Re:If you don't know, you can't do it

[fyngyrz]

Any decent programmer should be able to write a secure program. Read your input, reject it if it's not what you want.

That's true as far as it goes, but there are vulnerabilities in the language's collection of input, in the webserver's collecting of data and parsing of packets, in the network system layers below that, even, sometimes, in CPU instruction sets. And then there's social engineering, human error (just because you "can" write a secure program doesn't mean you *did*) and of course physical access is the nastiest risk of all.

It's really not as simple as we would like it to be. Unfortunate, but true.

Secure Programming book

[dwheeler]

Take a look at my book on secure programming: http://www.dwheeler.com/secure-programs/. I wrote it after I saw software getting broken into, again and again, for the same old reasons.

Re:If you don't know, you can't do it

[Xugumad]

That's fairly naive in web terms. For example, the application may carefully check an incoming string is valid for what it expects, but fail to correctly encode it on output and create a cross-site-scripting attack vulnerability (for example if the input contained a element). There's also a lot to check; for a number, it's not too hard, you check that the input is an integer/decimal as appropriate, and do range check if relevant. For a string it gets harder; length check is obvious, but what about checking character set? It turns out just finding out what the character set of an incoming string _is_, is difficult (blame IE): http://www.crazysquirrel.com/computing/general/form-encoding.jspx

Then you get cases such as CSRF (cross-site request forgery) attacks ( http://en.wikipedia.org/wiki/Cross-site_request_forgery ), where the user is fooled into clicking a link that sends a request to the web site, If they're logged in, the browser will typically send appropriate cookies, meaning from the server point of view the user has sent an entirely valid request.

OTOH, to say "If you don't know, you can't do it", is hopelessly defeatist. I would not start with a security-critical web application any more than I would start with any other security-critical application, but you can learn this stuff. Alas, it does take time...

Re:If you don't know, you can't do it

[TheRealMindChild]

Well, that doesn't say much for your family because it was rather easy to socially engineer you mom's pants off

Re:If you don't know, you can't do it

[Anonymous Coward]

That's untrue. You can assume the worst and protect your application by following secure coding checklists, code reviews and static analysis. You don't need some sort of reformed hacker on your team in order to be effective.

Yeah. All You Have To Do Is... <sarcasm>

Expect to be cracked. Unless your system is too boring and valueless to attract attackers, it will be targeted. If it IS boring and valueless expect to get targeted by automated attackers anyway. Buy insurance. Both the money kind and the technical kind (good offline backups, etc.).

Expect your costs to go way up. Secure and "Git 'R Dun!" don't go together any more than "welding" stainless steel pipes with duct tape does. It's going to take longer and cost more. In addition to the development cost increases, there will be maintenance cost increases, plus you should be running more tests, audits and so forth.

Once you've adjusted your expectations, look at your tools and platforms. Windows isn't quite the security nightmare that it used to be, but I still prefer to avoid it as the OS for critical servers. Likewise, certain platforms have less-than-sterling security records (RoR, PHP, for example) where others are designed from the ground up with security in mind (Java Enterprise Edition). An "insecure" platform used in a secure way trumps a secure platform used in an insecure way, but overall, it's a good idea to start with a secure basis.

DON'T create your own security system. Most of the DIY systems I've seen can't stand 5 minutes with a 5th grader. Unless you are a full-time security professional, you'll end up with a ton of exploit points, new team members and contractors won't understand it or remember to apply it properly to new/changed code, and most DIY systems I've seen required integration into application code, meaning that changes to security can - and often does - break the business logic. J2EE has a built-in wraparound security system designed to fend off attackers before the application code is invoked and require minimal security code in the application logic. Most insecure J2EE systems I've seen ignored this capability in favor of DIY login code. I blame too many J2EE books that use "login screens" to illustrate application programming.

DO adhere to best practices. There's no excuse for SQL injection exploits or exploits that came from trusting that what comes back from a client is what's supposed to come back from a client. Likewise, don't keep passwords in clear text in your databases. And never, ever expect that the only way people will access secured resources is by following a predetermined pathway unless you're demonstrably certain that they had no other way.

DO read up on the literature. There's plenty out there on hardening networks, servers and systems. There's a whole genre of books on secure Java design and programming.

Keep up to date. New exploits show up all the time. Likewise, keep your software security up to date. Test early and often.

The question was, "What should I be reading?"

[TheEmperorOfSlashdot]

Not, "How can I write flawless code?," but, "What should I be reading?" The submitter showed no prior knowledge of exploits, so it seemed reasonable to provide him with a simple introduction to the kinds of exploits he may encounter and how they can be prevented.

Interestingly, the 2010 "OWASP top 10 vulnerabilities" have all existed for a decades - a competent developer flash-frozen in 1998 and thawed out today would be able to guard against all of those flaws. That's not good evidence for your position that the question "continually needs to be asked."

Re:If you don't know, you can't do it

[spike2131]

Any decent programmer should be able to write a secure program. Read your input, reject it if it's not what you want.

Writing a secure program is relatively easy. Building a secure system is difficult. This is largely because any system that performs any non-trivial task in this day and age will necessarily entail running large amounts of code written by someone else.

Re:If you don't know, you can't do it

[JWSmythe]

    You don't know how many times I've told people that. They're usually the same people who say "How could they have done it?", and then I have to break out years old writeups of the exploit.

    Case in point, SQL injection. I was talking to some web programmers who apparently have worked in a bubble, and learned everything from the books, but glossed over the part about "never trust user input". They didn't get it. I demonstrated a SQL injection against their code. Then they were willing to listen.

    Too many programmers see user input as being trustworthy. Back in the day, it was as simple as "don't allow ` or ; in lines you send to a system calls". People even screwed that up. Then it was "don't do system calls, do everything natively in your code". People ignored that. Then it became "never trust user input", and "sanitize any user provided data". It's sad but true, they still don't care.

    I've introduced people to hacking tools and methodologies. It's not so they can hack. I "encourage" them to try to hack their own code. Code it right the first time. Then attack it to prove that it is right. And keep trying to break into it. Learn better techniques, and teach me something. I don't mind in the least if a coworker can show me that I'm wrong. It's worse if a malicious 3rd party does.

    There's no excuse for someone not to know and use the same tools that attackers use, to defend themselves.

Re:If you don't know, you can't do it

[Pieroxy]

Any decent programmer should be able to write a secure program. Read your input, reject it if it's not what you want.

Clearly, this only demonstrates that you're as clueless about web security as the OP. But he has the advantage of recognizing his ignorance and asking for pointers, where you think you know it all.

Web-specific suggestion(s)

[IBitOBear]

[A:] Never accept form data via GET, always require POST.

I never understand why any web page, other than something like google search, will or wants to accept data that is part of the URL for any meaningful interraction.

Sure it's bookmark friendly but:

(1) GET contents are logged by default, and PIN-trap elligible in post-facto and blind ("fishing") legal actions, POST contents are not.

(2) GET is the verb used in things like IMG SRC="" requests, if all GET requests are incapable of incidental write operations then that whole category of cross-site-scripting attack is rendered moot.

(3) Because of item 1, the contents of your web server log(s) is, by default, promoted from a stream of tidbits to a first-tier security risk in need of secure archiving. [If you have followed good practices and separated your database machine and your web server onto separate platforms, for instance, then a compromize of your web server of the classic sort will net very little at all if all your logs say is "IP X.X.X.X GET http://site.tld/someform" and "IP X.X.X,X POST http://site.tld/somerequest". If action and identification information are passed around in your GET(s) then an attacker can learn that IP address A.B.C.D is the home of USER=Bob and so forth.]

Basically if people had _honored_ the designation of everything after the question mark ('?") as a _query_ _string_ in the HTTP specification, but not carried the SQL-burdened definition of "query" into the issue, a lot of web-pain could have been avoided.

Yea it might not be as bookmark friendly, but when is it ever smart to bookmark the POST of a filled-in form?

[B:] learn what a _real_ DMZ is (e.g. two routers with the public machines between them and the internet behind one end and the intranet behind the other, with very intense restrictions on what traffic can pass from the DMZ into and through the internet end and _both_ routers configured to _distrust_ _all_ connection attempts originating from the DMZ machines). Then implement this arrangement correctly. There are a bunch of rules for doing this right, and if you follow them your web service machine will be "stuck" in a deep warm hole of safety, in that what it can do will be greatly limited, which is at least as important as making sure that what can be done to it is limited. Most exploits require more than one path to the machine, for instance tricking the web server into "calling you back" with a telnet session or an FTP or SCP of bulk data. If the web server can only pass traffic from the one port (port 80 etc) off of the DMZ then even a successful compromize of the machine may be stopped from having any net effect.

[C:] Every machine in the DMZ is allowed to do exactly one thing. e.g. don't build a LAMP machine, build a LAP and a separate LM machine and place them very close together. This sort of separation can even be done with virtual machines. Just so long as the machines cannot peek at one another's storage etc.

This is not mainstream wisdom, but it is out there if you look for it. (e.g. I didn't make all this stuff up myself. 8-)

There are lots of things that are easy, but not always cheap, to do that could make the world much safer.

They just aren't in the five-days-to-your-web-presence quick-start guides to web servers.

Re:don't use a framework

[Terrasque]

Rule 1: Do use a framework.. A good framework have already been widely tested and hardened, and will help you avoid stupid mistakes.