Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Writing Hardened Web Applications?

Unknown Lamer posted more than 2 years ago | from the i-hear-plain-text-password-databases-are-secure dept.

Programming 333

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


If you don't know, you can't do it (-1)

Anonymous Coward | more than 2 years ago | (#38567458)

Simple as that. If you don't know the hackers methods, you can't stop them.

Re:If you don't know, you can't do it (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38567500)

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


Re:If you don't know, you can't do it (5, Insightful)

FormOfActionBanana (966779) | more than 2 years ago | (#38567946)

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

Anonymous Coward | more than 2 years ago | (#38568062)

Any decent programmer should be able to write a secure program. Read your input, reject it if it's not what you want.
I've always been partial to the guide this guy writes http://www.dwheeler.com/secure-programs/ It's not specifically focused on web app, but an experienced programmer like the OP should be able to pick up the concepts solidly.

Re:If you don't know, you can't do it (4, Insightful)

fyngyrz (762201) | more than 2 years ago | (#38568394)

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.

Re:If you don't know, you can't do it (4, Insightful)

Vellmont (569020) | more than 2 years ago | (#38568188)

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.

Re:If you don't know, you can't do it (0, Redundant)

Anonymous Coward | more than 2 years ago | (#38568306)

1) Secure all the attack vectors: CHECK
2) Keep all the office machines up to date and scan email attachments: CHECK
3) Realize that #2 is #1: CHECK
4) Call BS on previous post: CHECK

Re:If you don't know, you can't do it (4, Insightful)

TubeSteak (669689) | more than 2 years ago | (#38568354)

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.

So your intranet apps aren't secure? (-1, Flamebait)

Stormthirst (66538) | more than 2 years ago | (#38567482)

Users always have ways of breaking apps in completely unintended ways. If you can't harden your intranet apps from 'ordinary' users - not sure you've got much hope against malicious intent. Intranet apps should be written as if it were posted on the internet for all and sundry to see and have a go at.

What the Fuck?! (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38567672)

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?! (0)

Anonymous Coward | more than 2 years ago | (#38567860)

Take your own advice first.

Re:What the Fuck?! (3, Insightful)

MrMarket (983874) | more than 2 years ago | (#38568328)

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

Web Applications aren't different (5, Insightful)

Elgonn (921934) | more than 2 years ago | (#38567502)

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 (4, Informative)

rsilvergun (571051) | more than 2 years ago | (#38567650)

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 (5, Insightful)

b4dc0d3r (1268512) | more than 2 years ago | (#38567818)

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 (0)

Anonymous Coward | more than 2 years ago | (#38568146)

I might be splitting hairs here a bit, but there are a number of things I allow on our networks that rely on people not being completely stupid or malicious. Yes, if someone trashes their part of a file server I have backups. I also keep journaling on so I have a record of everything that goes in and out of the building... but I don't prevent people from sending files out. When I write a service I carefully consider account security. But ultimately I end up trusting people not to share their credentials. I'm sure you get what I'm saying.

I figure there are IT problems and there are administrative problems. You can't cover every vector without a pair of scissors... which kinda defeats the purpose of having technology in the first place.

Re:Web Applications aren't different (5, Insightful)

nahdude812 (88157) | more than 2 years ago | (#38568244)

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.

Can you trust a network because it's intermal? (3, Insightful)

gwolf (26339) | more than 2 years ago | (#38568228)

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:Web Applications aren't different (4, Informative)

tysonedwards (969693) | more than 2 years ago | (#38567756)

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 (4, Insightful)

Thiez (1281866) | more than 2 years ago | (#38568316)

> 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 (1)

KevMar (471257) | more than 2 years ago | (#38568260)

There is a huge difference though. It is true that you should not trust any clients. But many people make incorrect assumptions.

They think that when you are working internally, there is a very small number of clients that can possible connect to it. The odds of a hacker getting onto your network are small. So of course it's secure, it's on a server behind a firewall. Opening an application to the internet strips those security blankets away.

To be honest, I think we all do a little of that too. We do what we can to write secure code internally. But we hesitate a little every time we think it may end up open to the wile. I see it as a scary door to open. We can't be 100% confident that we thought of everything, just like we can't be 100% confident that its bug free. It never is. A good student in the art of code should always seek to find more ways to secure public facing applications.

internet explorer (5, Funny)

Anonymous Coward | more than 2 years ago | (#38567506)

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 (0)

Anonymous Coward | more than 2 years ago | (#38567862)

Where the fuck to you live? All of the big banks I've looked at and worked with in America work with and support, Firefox, Chrome as well as Internet Explorer
https://www.key.com/personal/online-banking/personal-online-banking.jsp (they don't list Chrome, but Chrome works just fine)

Re:internet explorer (0)

Anonymous Coward | more than 2 years ago | (#38568014)


What happens when it gets hacked? (2)

ka9dgx (72702) | more than 2 years ago | (#38567510)

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! (5, Funny)

cultiv8 (1660093) | more than 2 years ago | (#38567518)

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

Re:EULA baby! (0)

Anonymous Coward | more than 2 years ago | (#38567668)

They could always steal your money

Re:EULA baby! (1)

Anonymous Coward | more than 2 years ago | (#38568080)

They could always steal your money

No they can't steal your money, the EULA has a clause in it so that to get on the site the person has to promise not to hack anything.

I fail to see what could possibly go wrong.

Maximum security, unplug the ethernet wire (1, Insightful)

youn (1516637) | more than 2 years ago | (#38567520)

and turn off the computer... and hopefully that will keep your data secure :)

Re:Maximum security, unplug the ethernet wire (1)

hedwards (940851) | more than 2 years ago | (#38567898)

If you really want to secure it, you'd weld the case shut and fill the jack you plug the power cable into with epoxy. Of course the computer won't be useful afterwards, but it will be secure.

Re:Maximum security, unplug the ethernet wire (0)

Anonymous Coward | more than 2 years ago | (#38568288)

You forgot to remove the keyboard, mouse and monitor and epoxy those ports closed as well.

Start with the W3 guide to secure CGI programming (5, Informative)

TheEmperorOfSlashdot (1830272) | more than 2 years ago | (#38567526)

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

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

Re:Start with the W3 guide to secure CGI programmi (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38567582)

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

Re:Start with the W3 guide to secure CGI programmi (1)

inviolet (797804) | more than 2 years ago | (#38567608)

http://www.w3.org/Security/faq/wwwsf4.html [w3.org] Once you understand the things they recommend and WHY they recommend them, you won't need to ask this question anymore.

You can also spread your application out into layers. From your request I assume you will be collecting and/or publish sensitive data. It may be possible to divide that process into sections, and spread the seconds over three different machines, with custom-written interfaces between them. That way, when (not if, but when) your world-facing server gets pwned, the pwners will probably be unable to immediately pull anything useful out of the second section (on the second machine), since it isn't using any ordinary method (e.g. HTTP on port 80) to publish data. This arrangement, like a bank vault, is not perfect defense, but it does give you more time to notice the breach and react.

Re:Start with the W3 guide to secure CGI programmi (4, Insightful)

Chuck Chunder (21021) | more than 2 years ago | (#38567964)

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 [owasp.org] is a pretty good starting point.

Re:Start with the W3 guide to secure CGI programmi (4, Insightful)

nahdude812 (88157) | more than 2 years ago | (#38568332)

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

Easy answer (2)

msobkow (48369) | more than 2 years ago | (#38567538)

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 (1)

Angostura (703910) | more than 2 years ago | (#38567744)

I suspect the OP was hoping to make his app as secure as a bank's Web-based account management system

Re:Easy answer (3, Informative)

msobkow (48369) | more than 2 years ago | (#38567792)

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 [gov.sk.ca] 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".

Re:Easy answer (1)

msobkow (48369) | more than 2 years ago | (#38567850)

Aside from that, there is no mention of what kind of web server technologies are to be used. I seriously doubt anyone can make many useful suggestions for how to secure an application when you don't even know what tools and languages are to be used to develop it.

Itemize your security requirements, then filter your tool options based on whether they have features to enable or support those requirements. Find out if it's possible to address any gaps through custom code.

Only then can you seriously think about getting a checklist together of guidelines for implementing security with the chosen tools.

Asking the security questions before selecting the toolkits is a bass-ackwards approach.

Yet there seem to be hundreds of "Slashdot Security Experts" willing to provide advice without understanding the question.

Simple. (0)

Anonymous Coward | more than 2 years ago | (#38567542)

Just use an odd number of ROT-13 encryption layers.

Filter EVERY input right at the start. (4, Informative)

unity100 (970058) | more than 2 years ago | (#38567550)

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. (0)

Anonymous Coward | more than 2 years ago | (#38567628)

While this recommendation is solid in terms of what I believe you're trying to say, I'd go one step further with it and say all input should be aggressively checked for known good values. In various languages, this can be done with regular expressions checks, and Perl lets you go one step further by turning on taint mode for programs. Taint mode forces all external input to be checked before it's used for anything "dangerous," and while it doesn't prevent programmers from doing bad (stupid) checks on input, it does immensely help with cases where something didn't get checked by accident.

Re:Filter EVERY input right at the start. (1)

unity100 (970058) | more than 2 years ago | (#38567718)

concept 'filter' includes regular expressions against any kind of code execution attempt or injection attempts.

Re:Filter EVERY input right at the start. (0)

Anonymous Coward | more than 2 years ago | (#38567894)

concept 'filter' includes regular expressions against any kind of code execution attempt or injection attempts.

That assumes you can enumerate the full range of possible attacks (including those not yet invented), and how they might be encoded. Far better to make regular expressions based on what is expected and to handle data in such a way that it cannot be executed, injected or treated as part of an SQL expression (ie, don't use string concatenation to create query strings...).

The real problem is defining what is expected. I've seen many data entry forms that assume people have only two names, that houses have numbers, that all postcodes fit into the US Zip pattern etc.

Re:Filter EVERY input right at the start. (1)

FormOfActionBanana (966779) | more than 2 years ago | (#38567920)

Well, you weren't very specific. When you say "filter" most people would construct a blacklist, which is the wrong way to do it.

Re:Filter EVERY input right at the start. (1)

BitterOak (537666) | more than 2 years ago | (#38568208)

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.

And remember, filtering input is only half the story. The other half is to harden the server itself by using a good, solid, external hardware firewall, and being careful to run only those services which are absolutely essential. And make sure all those services are patched and up to date. It does no good to harden your web app in the extreme if you're running an old and buggy ssh server on the same system.

Good start (2)

lazycam (1007621) | more than 2 years ago | (#38567552)

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:Good start (0)

Anonymous Coward | more than 2 years ago | (#38567736)

Govt has public info /standards for security. "Art of Deception" is trendy, but makes a good point that no matter how secure you make you site, people will be your weakest link. If digital certs for per client is an option, go for it. Some book stores carry things like "web security pocket guides". These are usually older techniques, but willI give you apapa's base to workcomplain on. Better books can be found on amazon. These will at least get you started and thinking about security. If you can find a friend that deals with security, that would be best. Pick his brain. With your request, you're almost asking for someone to teach you how to expect the unexpected.

An experienced developer? I doubt it (0)

Anonymous Coward | more than 2 years ago | (#38567566)

How can an "experienced developer" have such a poor understanding of basic security issues?
Anyhow, starting with learning how to use a spelling and grammar checker and post again (... clueless of what is requires ...).

Re:An experienced developer? I doubt it (0)

Anonymous Coward | more than 2 years ago | (#38568182)

Anyhow, starting with learning how to use a spelling and grammar checker and post again (... clueless of what is requires ...).

Easy sude, it was a typo. The 's' is right next to the 'd'. Some people be such souches.

There is a book about secure Java programming (0)

kvvbassboy (2010962) | more than 2 years ago | (#38567574)

There is a book about writing hardened Java code, meant for advanced Java programmers. It was even featured on ./ a couple of months ago, but I don't really remember the book title. :\

Hopefully someone else will remember it.

Yea I know, pretty useless post.

Re:There is a book about secure Java programming (0)

Anonymous Coward | more than 2 years ago | (#38567600)

There is a book about writing hardened Java code, meant for advanced Java programmers.

Citation needed.

And, minimize damage. (4, Insightful)

unity100 (970058) | more than 2 years ago | (#38567584)

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.

Vulnerabilty Scanner (2, Informative)

Anonymous Coward | more than 2 years ago | (#38567624)

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

design in damage control (1)

Anonymous Coward | more than 2 years ago | (#38567630)

Design in damage control. Know what you are going to do when you discover a site has been exploited. Consider how you will even find out if this occurs. Often times probes for exploits causes software to crash a few times. Signatures of key binaries that are periodically checked can be helpful as well.

Encrypt information in a way that the keys to decrypt are not immediately available and the keys do not decrypt everything. (There have been some interesting developments in SQL servers that do just that)

Compartmentalize everything. Try to isolate components of your services such that each one has to be exploited individually.

Track mailing lists for security, monitor versions and patch levels of software used in your environment. Make sure you don't focus your attention only on the 0-day issues, most hacks are done against relatively old flaws.

Sometimes newer versions of software are less secure. There is a large community of people who check out new releases and patches, stand on the backs of giants whenever you can.

Get IIS 4 (5, Funny)

Billly Gates (198444) | more than 2 years ago | (#38567642)

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 (5, Informative)

LouTheTroll (1093917) | more than 2 years ago | (#38567654)

Be sure to checkout out all of the fine resources at http://www.owasp.org./ [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 (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38567656)

Can the Slashdot community recommend good websites?

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

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

Be paranoid (trustno1) (5, Insightful)

gman003 (1693318) | more than 2 years ago | (#38567680)

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) (3, Informative)

KevMar (471257) | more than 2 years ago | (#38568384)

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.

Hire someone. (0)

Anonymous Coward | more than 2 years ago | (#38567686)

Plenty of people make careers out server-side security, and I think you should hire such a person. If you *need* that level of security, you also need someone experienced in that particular subject matter; someone whose life work has revolved around exactly that. Security is a constantly changing thing, and if you try to learn it all yourself, you're likely to *something*. You'll also have a very hard time keeping up with the constant changes, and if you get lazy, focus on something else, and let your guard down, you'll pay the price.

That's not to say you shouldn't educate yourself on the matter. But please, hire an expert. If you succeed, my personal information just may end up on your site someday and I want it to be secure! ;)

Banks are clueless too (1)

Anonymous Coward | more than 2 years ago | (#38567698)

Banks are clueless about internet security too!

How many are still using TLS v1.0?
How many are still insisting on limiting password lengths?
Exactly how does a "site image" add to any security? I've never seen any image other that the "good" one for logins. Idiots.

On to the real answer to your question.
* Don't use apache as a front end.
* Don't use Php, Python, ruby at all.
* Don't allow any user inputs to be passed to any DBMS without extremely strict filtering.
* Patch constantly.
* Have redundant systems in different states.
* Have monthly security audits performed by qualified pen-testers.

Or you can outsource everything and put penalties into the contract to protect your company from liability. "Indemnify" is the word you seek, young Padawan.

You are clueless as well. (0)

Anonymous Coward | more than 2 years ago | (#38568010)

You are clueless as well. The site image is so the end user can verify that somebody isn't spoofing the bank's website with a stolen or similar ssl cert.

And Always use prepared statements.

Business sense (1)

Sepultura (150245) | more than 2 years ago | (#38567702)

You don't say whether you're developing this for-profit or for pleasure, but I'll assume the former because if you're doing something that truly needs to be "100% rock-solid, unhackable" and you're not getting money for it you're just asking for trouble. Eventually something will happen, and you'll be sued. Then how are you going to pay for lawyers?

So, assuming that you're doing this for-profit, you need to develop some business sense. Effective business people hire specialists to do what they can't, as they know that their time is better spent focusing on their own areas of expertise.

So develop what you feel comfortable with, then hire a pro to harden it and/or deploy it, whatever you need. Also think about professionals for your accounting and (dare I say it) law advice as they can be the difference between profit and failure in our economy, unfortunately.

not only prevent, but also mitigate (5, Insightful)

OleMoudi (624829) | more than 2 years ago | (#38567714)

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 [codahale.com], the data will be nearly useless.

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

Layers (4, Insightful)

jbolden (176878) | more than 2 years ago | (#38567728)

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.


Joe U (443617) | more than 2 years ago | (#38568064)

As someone in this field for far too many years, it's great to find someone who pretty much outlined my strategy for secure web apps.

The rules are: All input is suspect, all users are suspect, deny access to everything and go from there.

On a sad note, I've yet to find a boss willing to do it right, there's always a shortcut to save time or money.


jbolden (176878) | more than 2 years ago | (#38568254)

All input is suspect, all users are suspect, deny access to everything and go from there.

Nicely put. I agree. And possibly -- internal users are suspect as well.

I agree with you on money saving. Very few people want to pay for security, except for security companies and the military. Web companies aren't bad either because they have to deal with so many attacks. But in general most people want to claim security without the spending.


Joe U (443617) | more than 2 years ago | (#38568372)

Nicely put. I agree. And possibly -- internal users are suspect as well.

I'm actually in the mindset that all users, including the administrators, are suspect. I get a lot of flak on that, but personally, I have yet to see a reason to give anyone complete direct access to raw data without making it difficult.

Also, for some reason, many devs don't like the whitelist method for validating input. Never really understood why.

Re:Layers (0)

Anonymous Coward | more than 2 years ago | (#38568284)

There are companies that sell automatic scan services. Cheaper than manual penetration testing.

The automatic scanners have advantages and disadvantages compared to manual testing. They don't find all types of problems (good manual testers find issues that automatic scans can't detect), but for the problems they cover they find everything--they don't get bored or sloppy and try everything.

I'd recommend one, but I work for that company.

Niche Setup (0)

Anonymous Coward | more than 2 years ago | (#38567754)

I've seen a Tor setup with FreeBSD + nginx where nginx acccesed the confidential data over a high speed serial link to a big black box. Reduced the attack surface of the data provider and the serial interface allow for easier unit testing during development. The setup was resistant to non-physical attack scenarios against confidentiality and integrity, however, digital signing, hashing, error correction and end-to-end encryption (with the data provider being the endpoint not the web service) was employed. However, this service was providing a M2M service not serving human users. I some CAs tend to use similar methods when isolating their HSMs.

some good rules to follow (1)

bleedingsamurai (2539410) | more than 2 years ago | (#38567764)

I think the best, most general three rules are: 1) create the application to use the least privilege possible 2) always do bounds checking on buffers 3) create a generic function, subroutine, method whatever your paradigm uses that spits out some kind of error message and tries to cleanly close the program. this way you can have it call this code if something awkward happens that you haven't explicit told it how to act.

Learn to break them (4, Insightful)

DarwinSurvivor (1752106) | more than 2 years ago | (#38567846)

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/ [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.

Some tips (1)

Bucky24 (1943328) | more than 2 years ago | (#38567880)

I'm not very practiced in developing "hardened" web apps (mostly I've just worked with already written code that is secure), but:
Use as little javascript as possible (if you're planning to use web2.0 AJAX type stuff). It's almost laughably easy to change javascript after the webpage has loaded (Greasemonkey for example). If you're super good at programming clean secure C/C++ you might want to program your own webserver (servers like Apache are easier to use, yes, but they release security patches to them all the time, so they aren't THAT secure. A dedicated single program that only does a few things is likely to have less vulnerabilities). Barring that, make sure your webserver installation is up to date, this includes the PHP/Perl installation (or whatever language you are using), as well as your database server. Sanitize any input from the outside before putting it into a database (or really doing anything with it).

That's for your own server. Now, I assume you'll have users. You should implement a login "token" that expires after a certain time. This token can be any number of things. For apps I've worked on we usually use a hash that contains the login email, among other things, for easy checking. Make sure that every single request by the user contains this hash, and the hash is verified before any data is changed.
Use SSL or some other form of secure transport (https). This will insure (well not insure, but make it more difficult) that even if someone is able to snatch your user's packets (like if they are in Starbucks or something), they will have to decrypt them before they get a token (by which time it will have expired).

That's pretty much all I know as far as general security goes. I'd have to know more about what kind of application you are trying to create to be able to offer any more advice (and please, if someone sees something wrong with what I've written, don't hesitate to correct me. Like I said, I don't have a ton of experience with app security).

Re:Some tips (1)

mortonda (5175) | more than 2 years ago | (#38568040)

Use as little javascript as possible (if you're planning to use web2.0 AJAX type stuff). It's almost laughably easy to change javascript after the webpage has loaded (Greasemonkey for example). .

That really has no impact, as long as you make sure the server side validates all actions to be sure they are correct and allowed. Javascript is great to enhance the experience, but it does nothing for security.

Re:Some tips (1)

Bucky24 (1943328) | more than 2 years ago | (#38568134)

A friend of mine once had a router that used javascript based authentication that could be hacked using Greasemonkey. So don't do that, is sorta what I was trying to say. I suppose I could have said it better though....

Re:Some tips (1)

mortonda (5175) | more than 2 years ago | (#38568238)

Right; the key is, javascript can do nothing for security, only for interface enhancement. The security must be maintained only by the server side.

Security Engineering for Distributed Systems (1)

FormOfActionBanana (966779) | more than 2 years ago | (#38567888)

Yay for the OWASP recommendations. Also, read this book by Ross Anderson.

Buy a couple days from a security vendor like GDS or Cigital for a security architecture review. Good luck!

I do this for my day job.

You give banks too much credit (4, Informative)

Tony Isaac (1301187) | more than 2 years ago | (#38567910)

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 [slashdot.org]. 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.

Comprehensive with layers FTW (0)

Anonymous Coward | more than 2 years ago | (#38567922)

I am a senior Cisco network engineer with a variety of experience in both data networking (specifically around the datacenter infrastructure) and have found that the best approach to security is applying it in layers.

For example, one would not want to put a bank controller publicly facing the Internet and so they most commonly use a firewall to protect that server. Given that that server is not typically the server being used to provide web server resources to the Internet population, it is typically segmented with said firewall from the public facing web servers.

Furthermore, this also allows some good key functionalities down the road as the services base grows, for example, datacenter pods, efficient placement and usability of application load balancers and very specific firewall rules, which can prevent a lot of security concerns today and tomorrow.

However, one of the more important things in a web-based application is protecting the public layer of resources from everyday attacks. Some examples include DDoS style attacks and SQL injection attacks. The best application for DDoS attacks is a device that properly denies requests above what might be expected from a user within a certain time period. In regards to SQL Injection attacks, the key is filtering. EVERY INPUT FROM EXTERNAL SOURCES NEEDS TO BE VERIFIED AND VALIDATED.

Once you think you've got it, hire a firm to test that you are secure. What they find, use. If they don't find anything, they're not a good firm. Ask for examples of their pen tests before purchasing their services as some of them aren't that good.


Mod parent up (0)

Anonymous Coward | more than 2 years ago | (#38568048)

Some good stuff here.

Also, the authentication/authorization/cryptography architecture has to be carefully designed. Most commercial web sites offer an unencrypted home page for all users on port 80, and an SSL/TLS (encrypted) sessions for user login and session data. The latter requires a PKI infrastructure, so secure storage of the private keys is crucial.

Obviously this is all just scratching the surface.

Back to basics (1)

thogard (43403) | more than 2 years ago | (#38567924)

1950's computer science used a model of "input/output/processing/storage" and it worked well for most projects but it also kept programmers minds on data flow. Find out how that data flow can be abused and prevent it. The simpler a system is, the few bugs it will tend to have.

Also don't use systems that want to load up hundreds of packages to do something simple. Software complexity is the root of all security issues.

Start by eliminating low-hanging fruit (1)

93 Escort Wagon (326346) | more than 2 years ago | (#38568004)

You can start by reading up on what's frequently been the vector for system break-ins elsewhere, and avoiding those mistakes. For instance:

- Don't write in php, and especially don't rely on a php-driven framework. While no language is perfect, serious php exploits still appear with alarming regularity (as compared to, say, perl or python). Also be sure to disable php on your server if possible (e.g. just redefine all php-related extensions to be treated as text/html).

- If you need an SQL back end, learn how to use placeholders/prepared statements.

- If you need an SQL back end, make sure your scripts run with the least privileges necessary. If a given script only needs to query a database, for example, that script should connect as a user that only has read-only access to the database.

Complexity, Time and Money Prevents Good Security (1)

CodeBuster (516420) | more than 2 years ago | (#38568042)

Anyone who has actually worked for a time in web development will tell you that tight schedules, shoestring budgets and large sites, with many moving parts, all conspire to ensure that security holes exist in just about every non-trivial web app of any meaningful size. It's not that we're unaware of SQL injection, validation of inputs or even cross site scripting, we just don't have time to check and test everything and all possible interactions before we have to move on to something else (thank you MBAs). The people who write the checks don't care about security as much as they care about new features, being buzzword compliant or getting everything "into the cloud" and most of all: being on time and within budget . Under these circumstances, something has to give and that something is usually security because few clients care enough to pay, in both time and money, for what good security really costs. Until companies are held liable instead of just saying, "whoops" and advising people to check their credit reports for the next N years, this will continue. One good example where increased liability is leading to better security is in electronic medical records and related healthcare software due to the penalties imposed by HIPAA [wikimedia.org] for breaches of protected health information. As soon as breaches go straight to the bottom line companies start caring.

To be as secure as a bank ... (1)

Skapare (16644) | more than 2 years ago | (#38568086)

... then just set the password for root to "rewt" and your done.

Seriously, the way banks do things should absolutely never be a model for security. Run BSD (not Windows, not Mac, and not Linux). Find the smallest open source web server that can do what you need (but absolutely not Apache), and review the source and history of bugs and exploits. Or just write your own. Avoid languages with lots of modules if you can, and certainly avoid those modules. As much as you can you need to be writing all the code. Most of the open source stuff out there was not written with "rock solid security in mind", or was any of the commercial stuff. But at least with open source you can review the code, so if you can't write the code, then review some open source.

Well... (1)

stevenfuzz (2510476) | more than 2 years ago | (#38568112)

Relax, pick up your phone, and call a system administrator. There is pretty much no way you are going to set up an unhackable web server unless you know what you are doing. Even sysadmins with 20 years security experience make security mistakes setting up systems (Source: All the huge websites hacked by Anon this year). Keep your mind on the application and let the sysadmin worry about it's delivery.

A Good Book - The Tangled Web (1)

NaCh0 (6124) | more than 2 years ago | (#38568158)

Coming from a windows environment, you've probably already lost.

But here is a book to show you how much you don't know (in a platform agnostic way):

The Tangled Web [amazon.com] by Michal Zalewski.

Also, forget all of the advice above about starting by writing your own webserver. That's a fool's errand.

owasp (0)

Anonymous Coward | more than 2 years ago | (#38568218)

follow that and you should be alright.

Validate your inputs! (1)

SplashMyBandit (1543257) | more than 2 years ago | (#38568220)

First, make sure your software is written correctly. That is, use Java with a lot of unit testing and good coverage using something like Cobertura.

Now, given a correct program the only way it can fail is if it accepts bad input from the user. This means you need to write your program where you validate your inputs as early as possible. If the input is clean your program will not fail except for something out of its control - such as a resource failue (bad network, hardware failure etc). The hard thing is that it is not always possible to validate the input as soon as it is received (which is the ideal case). This means that all parts of your program must validate the input and if something is awry they stop the operation (with an appropriate explanation of why processing is being refused).

he reasons why programs fail and are hacked is that most programmers refused to check their preconditions ("waahhh! it takes extra lines of code and obscures the real work"). Checking preconditions is something that most Java programmers and almost all C++ programmers fail to do, which is why there is so much flaky code out there.

The last thing I like to do is to check that my programs can handle the bad inputs and also resource exhaustion conditions. If you don't check for it then your program will never get it right and will behave unexpectedly given strange inputs (ie. is hackable) or operating conditions. One of the most important things you can do is to log not only what went wrong also log the bad input and information about why the decision to fail is made. Most people are shitty at logging. Assume you will never be able to re-run the program to find the bug (some bugs are rare, and can only be found due to a set of circumstances in the production environment). Hence, you will only be able to diagnose and correct any faults given the information you choose to log at the point the failure is detected.

Does stringent checking preconditions (including inputs), properly logging for diagnoses and good unit testing coverage work? yes, but it as only as good as your design (which I'm sure others will discuss). I've produced systems that handle millions of transactions in the course of a week and they run without fault, regardless of the shit that clients throw at them.

Just Validate (0)

Anonymous Coward | more than 2 years ago | (#38568242)

When it comes down to it, validation and cleaning user input is pretty much the main thing you have to worry about. Just make sure all form data and cookies are clean and in the right format! Other than that, just use your head. EX: use hashes to store passwords, actually do permission checking, ect. It's not rocket science.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account