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.

Re:Web Applications aren't different

[TheLink]

You could sign the form/url (and have a random salt). So the injected javascript has to figure out how to generate a valid signature.

For example: Slashdot doesn't do any checking so you can post a logout url, and if anyone's browser somehow loads that url, they get logged out. But if you add a random salt and a signature and tie it to some other secret, the attacker will have to generate or copy the logout url from somewhere.

The logout url will still have to be derivable by the browser, otherwise the user won't be able to logout, so in theory some clever javascript would be able to figure it out.

However stuff like CSP ( https://wiki.mozilla.org/Security/CSP ) might reduce the amount of successfully injected javascript, and other protections could reduce the domains that the injected javascript can affect.

So it's an arms race, but all you need to do is make it hard enough so that the attacker tries something/someone else instead.

Re:Web Applications aren't different

[Terrasque]

You know that. I know that. But someone with little or no experience with web browsers probably won't know that.

My point was: a web app can't be treated like "any other networked program" because the clients and protocols have some unique considerations you have to keep in mind.

I've programmed for the web for almost 10 years now, and have always tried to keep a focus on security. I would hesitate to do a project like this myself, because I know there are a lot of ways things can go wrong. So many details to err on. Just look at HTTPS alone.. Is the site vulnerable to the BEAST attack? Are CA's still trustworthy enough? Is your server's SSL configuration actually secure (O hi, yes we accept anon key exchange, go ahead mr MitM)?

So many pitfalls.. Even Raging Paranoia(TM) would just be a good start, nothing more.

Now, look at the question.

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 clueless of what is requires to create a web server that is as secure as, say, a banking account management system.

My advice:
1. Learn HTML, JS and HTTP
2. Read up on "best practices" - understand them
3. Read up on top10 website problems, make sure you fully understand each and every one of them.
4. Read some details about various high-profile website hacks. See how a small, overlooked detail set the whole security tower falling to the ground.
5. Now you're starting to get the basic knowledge required to find who to hire to code this for you. Hire a team to actually code it.

Re:Web Applications aren't different

[tysonedwards]

You set functions within your code that will not be writing to use a read-only connector into your data store.

You can also assign a class for your user accounts themselves where if they are only to "read" data and not actually add anything that their read-only connector takes precedence in execution.

If a user shouldn't be adding records, don't provide them with the privilege.

If a user shouldn't be modifying records, don't provide them with the privilege.

If a user shouldn't be deleting records, don't provide them with the privilege.

And finally, you validate any requests that will result in adding, changing or deleting data in your code *prior* to running against your database to ensure that things are on the level.

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.

Re:internet explorer

[Fluffeh]

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

Do they at least stop you looking at other peoples accounts if you change the account in the address bar? If not, you haven't dealt with Citibank.

What happens when it gets hacked?

[ka9dgx]

It will get hacked, it's just a matter of time. If you have data that is getting uploaded, then needs to be secure after that, consider using a unidirectional network, also known as a "data diode", which can only send data in one direction.

If you can't hand the administrator account passwords to someone and rest easy, you shouldn't be counting on it to be secure.

EULA baby!

[cultiv8]

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

Re:EULA baby!

[VJmes]

The day will come when a class action is filed when thousands of users have their personal details stolen and that clause will be challenged in court. I really don't see a judge ever excusing a company's gross negligence in keeping user data private because customers "signed" away their right for remediation or compensation.

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.

Easy answer

[msobkow]

I am clueless of what is requires to create a web server that is as secure as, say, a banking account management system

You can't.

There is no way to provide the same level of security as an in-house application running on dedicated terminals and a dedicated network as with the banks' teller terminals and ATMs.

And that's because you have no control over the browser and it's plugins, so you can't stop them from mismanaging or misrepresenting the data, custom code in modified copies of open source browsers saving pieces of secure pages that you never meant to see a hard drive, etc.

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".

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.

[Corbets]

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.

A lot of the posters on this story talk about filtering, and that's absolutely right - but filter on a whitelist, never a blacklist! Think about what inputs or input forms are acceptable rather than trying identify all possible bad inputs. If you go the blacklist approach, it's almost certain that someone more cracking-minded than you will identify something you missed.

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.

Re:Filter EVERY input right at the start.

[swalve]

I would agree with that 100%. In addition, using different machines for different filtering tasks. You might have a firewall that keeps bad stuff out of your network, but then have another firewall type of machine that protects and sanitizes only your app server. And have different physical networks. Nobody, not even system admins, should be able to get to the machines from the outside facing network.

Good start

[lazycam]

Slashdot is a good forum to ask this type of question. I'm sure you'll find a few individuals who work securing financial systems, but you are probably better off having a one on one with someone with some real experience. Data security methodology will likely be a hot topic this year among management and security researchers, so you should check for conferences in your area, or budget some time to take a weekend or too off. I doubt a book will teach you everything (often year old information), so I strongly recommend you seek someone out for a short course or walk through. Also, be sure to sign up for a security list serve so you get the most up-to-date content and questions being asked.

Re:Start with the W3 guide to secure CGI programmi

[Anonymous Coward]

Also read The Web Application Hacker's Handbook. (google: wahh)

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.

Re:And, minimize damage.

[naasking]

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.

I disagree. You can mitigate many risks by using a proper language (memory safe) or web framework which handles user input and session/CSRF protection. You can mitigate all risks by properly using a theorem prover to guarantee your implementation has all the important properties to guarantee safety.

Vulnerabilty Scanner

[Anonymous Coward]

You'll never be 100% secure but take a look at something like http://www.rapid7.com/products/vulnerability-management.jsp. Its the company who bought metasploit(http://en.wikipedia.org/wiki/Metasploit_Project) which is a common penetration testing framework.They have a community version that free you can run against the server if you own it, if you don't own the server you can check with the hosting company and see if its ok to run to verify everything is fine. Its for banking you should look at http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard as it has standards for financial data

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.

OWASP - Open Web Application Security Project

[Anonymous Coward]

Can the Slashdot community recommend good websites?

Check OWASP: http://www.owasp.com/index.php/Main_Page

• - read the Top 10
• - Join a local chapter

Also, budget for an engagement with professional penetration testers. Best they find the holes before the black hats do.

Good resources at Open Web Security Application Pr

[ziani]

I recommend taking a look at The Open Web Security Application Project. There are a significant number of resources listed on this topic.

Best,
Z

What the Fuck?!

[Anonymous Coward]

Can you answer his question? Do you have any advice on how to harden the web site/service? Any books you know he can read? Any web sites or software good for this? NO? THEN SHUT THE FUCK UP! For once either answer the question and no fucking sermons.

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.

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:Layers

[Enleth]

This. Especially the layers.

If you can, split the application in two parts - the font end running on a world-facing web server and a back end on a private network. Use a well-defined, high level protocol for communication between the two. If you can afford (literally, it's just a matter of throwing more hardware at the problem) some overhead, use a text-based serialization format with a solid, well-tested parser. The simpler, the better. Check every single request at the backend in every possible way, data sanity checking at the door is crucial. Maybe sign the requests - won't do any good if someone breaks into the frontend boxes (because they will get the private key then), but will make it impossible to somehow impersonate those boxes without compromising them first. Sign responses. Generate and deploy new keys and certificates often. Use prime numbers (look up cicada principle) for intervals between key changes to avoid being predictable, if you're truly paranoid. Log everything, offsite. Send the logs over a smart network bridge that will let through logs, just logs and only logs, and only in one direction just to be sure. Make this bridge the one and only thing connected to the log server, other than the power cable, a monitor, a keyboard and a tape drive. Preferably use a similar bridge between the frontend and the backend servers, have it do sanity checking of all passing traffic in addition to the checks at the backend. Have different people implement the checks at the backend and at the bridge, do not let them share code. Preferably, use two different parsers for your serialization format of choice. If you can, put the databases on a third layer behind the backend (so that it's only doing business logic, not data storage). Try to embed some basic security in the database itself, especially data integrity checks. Have it roll the transaction back, tell the backend to bugger off and raise an alarm if it's told to do something that doesn't quite fit with the nature of the data. And so on, and so on, and so on. It's all about assuming that every single part of the system can and will contain security holes, but with so many layers, cross-checks and variations on the security measures (like using two different parser implementations for the same check), the probability of someone finding a usable chain of exploits is absurdly low. Remember, exploits have to be used several at a time to actually break into a system and not just DoS it.

I wonder if any web applications that properly implement all those things and more even exist, but it wouldn't hurt to try to make one, if you have the funds.

Oh, and one last thing. The most important one, actually. If you pull this off, your application might be so impervious to hacking in the usual sense of the word that it would be simply impractical to do that, not worth the time and effort. And guess what the determined hacker will probably do at that point? Dress as an air conditioning serviceman, show up at the facility, talk some shit into the guard and walk away with your data 15 minutes later, using equipment no more high-tech than a screwdriver. Or, if your guards are not as dumb as that, a *very* determined hacker might even employ themselves at your air conditioning service, cleaning or electrical work company and do the same the next time they *legitimately* show up at the facility. It's been done. In short, consider other aspects of security, moreso if you're actually a valuable target and almost unhackable through the internet.

Re:Layers

[jbolden]

I wonder if any web applications that properly implement all those things and more even exist

Yes, this sort of layered approach is common in most of the internet application services. I've worked with Yahoo and Myspace on parts of their infrastructure. They get an amazing amount of attacks.

Re:There is a book about secure Java programming

[DarwinSurvivor]

Did you just recommend a secure software book that you haven't even read...?

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.

Re:Learn to break them

[b4dc0d3r]

I've already commented, otherwise I'd mod this up. I sometimes program or modify in assembly language, ad I have to say, cracking an app here or there has made me absolutely paranoid when writing. I still think in machine execution terms when writing VB.NET. I consider what the CPU has to do to get the results I want.

Side effect, I was able to make a web service 30 plus times faster by changing maybe 4 lines of code. Because I know what the VM/Interpreter has to do, and I tell it to do the same thing a different way.

When you study the viruses and malware that has taken over IIS over the years, or your chosen platform instead, you get a different perspective on where things are important. Being able to do even a few simple hacks on a website will get you further than most safety tutorials. Be a black hat on your own website, sometimes this is called White Hat.

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: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

Web Application Firewall

[Stultsinator]

ModSecurity (or any other WAF) can greatly decrease the number and kinds of attacks that actually make it through to your application. And like a good firewall it can alert you when you're under attack. If you do nothing else, put this in place.

You also want to make sure your app is solid, so head on over to DISA and see what the military recommends. They have Security Technical Implementation Guides (STIGs) for just about everything in your architecture: http://iase.disa.mil/stigs/app_security/index.html

Once you have things built, test! Use some of the open source penetration testing tools to see if there are any known vulnerabilities in your stack. Try it with and without your WAF in place.

Finally, if you really need to go the extra mile, it's time to shell out some cash for professional penetration testers. They'll have a tool belt full of open source and proprietary tools and the good ones will even do a static analysis of your code.

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.

That wasn't the real reason to avoid using Perl.

[TheEmperorOfSlashdot]

Another reason that compiled code may be safer than interpreted code is the size and complexity issue. Big software programs, such as shell and Perl interpreters, are likely to contain bugs. Some of these bugs may be security holes. They're there, but we just don't know about them.

Major Perl vulnerabilities still crop up on a regular basis - on average, one or two a year. When was the last time you heard of a major vulnerability in the C programming language? And what "experienced developer" can't be bothered to guard against buffer overflow exploits?

The simpler the runtime environment, the more easily it can be controlled and problems can be avoided. Simple C has one of the simplest runtime environments of any programming language, making it perfect for use in high-reliability situations.

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.

what we did

[AlanBDee]

I worked at an insurance company, which holds a huge amount of personal information. Monitored and regulated by the Federal Government. To keep our system secure the primary server was locked out of the Internet completely. Internal operations were able to access the server from inside the building only. I was able to VPN in from a remote location and then access it but nonetheless the server itself had no public access. A public web server was setup with it's own database. Every night the system would go offline while the private server pulled/updated necessary information on the public server.

While I didn't set the whole system up as that wasn't my job there, the only thing I would change would be to add several tripwires with honeypot data. By that I mean placing fake or bad data in specific locations with a tripwire that would notify me if they were accessed.

I also have loads of experience in locking down PHP applications. First thing I do is filter all incoming parameters with regular expressions. Loop through all get, post, and request parameters. I only pass numeric ids so that's easy. I also specify what parameters I expect. On critical pages if any "unknown" parameters are sent it silently kills the page, return an empty response as if a critical error happened. (Note: Search engine spiders often append special parameters that identify them as spiders. If SEO is important to you then you'll want to account for those.)

Validate all public methods of your classes very well. It doesn't matter if it is validated multiple times, it's good to confirm it anyway. Finally, use the prepared statements in database queries. Worst thing you can do is, "SELECT * FROM MY_TABLE WHERE ID=".$_GET['id']. That's guaranteed to be injected... quickly. If I don't use a frameworks API, setup a OOP set of classes to handle the operations.

In the end, remember the two guys in the forest being chased by the bear. The one guy only has to run faster then the other to survive.

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:That wasn't the real reason to avoid using Perl

[Chuck Chunder]

Major Perl vulnerabilities still crop up on a regular basis - on average, one or two a year. When was the last time you heard of a major vulnerability in the C programming language?

Are you being funny? Perl is written in C and the (unspecified) "Major Perl vulnerabilities" are probably due to the lack of protection offered by C against developer mistakes.

Of course one could assume that it is only other developers that make such mistakes and by writing it yourself from scratch you would avoid them. You would most probably be wrong though.

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.

Re:Start with the W3 guide to secure CGI programmi

[0ld_d0g]

Yes. To have an exploitable buffer overflow, a programmer has to make a major mistake in the most fundamental area of programming

So programs without flaws are flawless. lol.

_Anything_ that reduces flaws is a good thing. That includes superior tools/languages or hiring better programmers. Like assembly, C forces you to think of a problem at the level of manipulating bits in memory and pushing them around, manually managing resources, etc. Such thinking is stupid, wasteful, and pointless and needlessly increases development time, testing and other various time costs. Nobody should use C unless there is a very specific benefit from it - Systems programming / performance oriented software / games / embedded software / etc. i.e. a very tiny subset of all programs.

Also, what decade are you living in.. wake up .. manually managing memory resources is not in any way the fundamental area of programming. It is not even required to learn about that to be a good programmer - i.e. A person who can create reliable and efficient solutions to problems using computers.

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:If you don't know, you can't do it

[Chrisq]

And then there's social engineering

Well, yes. But that only works against idiots.

Having worked on a banking website I can assure you that the requirements of a secure site include secure use by the average idiot. Of course the complete idiot will always defeat you. (Someone who has a smart phone configured as their SMS out of band authentication for their bank, the website bookmarked, and their password in an unencrypted file called "passwords", no lock on the phone which they then leave in the pub)

What was told to me

[hene]

While it can be considered as fact, that no system is unhackable, monitoring servers needs to be done. What was told to me when I asked this question from known hacker, answer was quite straight forward. It was while ago, so better software may be available.

SNORT
Tripwire
SE-Linux
keep server software up to date

You used banking as an example... good start

[LostMyBeaver]

Sure, there's a gazillion lines of COBOL code out there in banking, it would take FOREVER to replace, though there are more modern banking systems which provide a solid starting point and it could be done and it might cost less than running IBM mainframes. But there's another great reason for COBOL.

COBOL is a crippled language. Unlike most other languages where all the code is written in that language... or maybe with the help of one more language. COBOL is an insanely retarded language. COBOL is generally only used for processing things. RPG-IV or something similar is used for terminal user interfaces, web based systems can communicate with the COBOL back end and then COBOL would perform the transactions required. COBOL itself doesn't even store the data. Even though COBOL often has a crippled internal ISAM or possibly can use SQL. More often than not, COBOL is linked to a DB/2 database... which is more of a large scale ISAM as opposed to a SQL server. Think of it as the data store used by an SQL server. Records are searched for using archaic search methods based on classic database structures... more like how it was done with dBase, FoxPro or Clipper.

While I don't recommend writing code in COBOL... you should consider the mainframe model of development.

1) The web interface DOES NOT query data directly from the data store. Instead, it requests data from a broken on another server.

2) The other server is connected using a non-IP protocol. The only method of requesting data from the other server is through a simpler interface which is fully known. You can't ask for credit card numbers for example. This can be accomplished using Ethernet, but avoid using IP. It's far too big and hard to understand. Using Infiniband as a link is great because you can use MPI over Infiniband to send a message asking for data and then wait for a result. This sounds more expensive than it is... but Infiniband is pretty damn cheap until you need fabric switches. Point to point is pretty easy on the wallet. The key is, any machine accessing data on the database should not under any circumstance be able to define its own query. Add a new function with parameters for each query. It must be explicit.

2a) Ultimate paranoia. Critical information such as credit cards and social security numbers exist on a separate payment processing machine hidden behind that machine. All communication with that machine is performed over a dedicated data link such as a high speed serial port (you can get them in megabit+ speeds these days) and all queries performed on that machine will be 100% explicit and will guarantee that there is no possible means of requesting anything other than the last 4 digits of either number. Transactions are sent to that machine, it performs the transaction and responds back with "Yes or no!". If a single user has multiple credit cards... there can be a query function which returns the card type and the last 4 digits only.

3) Just like an IBM mainframe. NO C/C++ code compiled native. This is simply because C and C++ lack proper memory management for secure systems. People still use pointers when they should use classes and there's no run-time checking on these things. Instead run inside a VM type environment. I recommend using a web server running on top of Mono or on top of Java. Not a web server running Mono or Java inside of them. This way, there's a much higher amount of security involved. Yes, this can still go wrong... but the chances are much lower. Make it a requirement that all classes and functions which are used in the system are compiled for the virtual machine and DOES NOT call out of the VM... unless there is no alternative.

4) Port 443 is the only open port on the systems... no exception. If you run netstat -a there should be absolutely no ports listening other than HTTPS.

5) Hardware based load balancing proxy server. These are expensiveish... but if you get a hardware based proxy server that load balances by proxying HTTPS requests across your web servers, it'll m

Hire an expert

[kikito]

Documenting yourself will not hurt, but I think you must hire an expert to have that done correctly. Computer security is a field complex enough to warrant more than reading a couple books.

If your budget doesn't allow for this, then probably your client doesn't really need the kind of security they are asking for.

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.

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

[Ihmhi]

"Reformed hackers" reminded me of Kevin Mitnick and something that we solely lack as a security measure - social engineering countermeasures.

I honestly think adding in stuff like Challenge/response prompts would do pretty well for greatly reducing the possibility for social engineering towards the end of infiltration. It works for the military...

Re:Start with the W3 guide to secure CGI programmi

[nahdude812]

So $200 for vBulletin and $150 for vBSEO per developer. Wherever you're working, get out as soon as you can, if they can't spend $350 per developer on licenses, they're going to cut a lot of other important corners - like pay raises. Seriously, that comes out to $0.16 per hour. Even if you guys are entry level guys making $16/hour, that's still just 1% premium on your pay rate to grant a substantial amount of utility (plus the conflicts involved in multiple developers working in a common environment is going to cost you more than 1% of your time).

But let's accept for the sake of argument that your company's margins are so thin that they can't support shelling out for a few licenses. Couldn't they shell out for at least a single test server that isn't production? If you want to take the cheap route, make that test server a VM image and pass a copy out to all the developers so they each have their own dedicated environment on their local machine. Refresh that image time to time with a snapshot from production and everyone even gets reasonably real data to work against.

How do you guys do source control? What do you do if two guys both have changes in the same file? What do you do if two guys are trying to work in the same file at the same time as each other (thus potentially overwriting each other's work)? I worked at a place where they had no source control and no developer-specific dev environments. We had to do a lot of shouting across the room, "Anyone working on file XYZ in folder ABC?" We'd still get files overwritten by someone else's save. Very frustrating to test when you are making changes and sometimes they're there and sometimes they're not, because someone else keeps overwriting it. Got them on source control and split environments in no time, and they couldn't believe how much that simplified their day-to-day operations.