Forgot your password?
typodupeerror
Programming Security

Ask Slashdot: Writing Hardened Web Applications? 333

Posted by Unknown Lamer
from the i-hear-plain-text-password-databases-are-secure dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Writing Hardened Web Applications?

Comments Filter:
  • by Anonymous Coward on Monday January 02, 2012 @08:16PM (#38567500)

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

    Moron.

  • by Elgonn (921934) on Monday January 02, 2012 @08:16PM (#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?
  • by youn (1516637) on Monday January 02, 2012 @08:17PM (#38567520) Homepage

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

  • by unity100 (970058) on Monday January 02, 2012 @08:22PM (#38567584) Homepage Journal
    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.
  • by Anonymous Coward on Monday January 02, 2012 @08:27PM (#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.

  • What the Fuck?! (Score:2, Insightful)

    by Anonymous Coward on Monday January 02, 2012 @08:28PM (#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.
  • by gman003 (1693318) on Monday January 02, 2012 @08:28PM (#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.

  • by OleMoudi (624829) on Monday January 02, 2012 @08:31PM (#38567714) Homepage

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

    by jbolden (176878) on Monday January 02, 2012 @08:32PM (#38567728) Homepage

    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.

  • by b4dc0d3r (1268512) on Monday January 02, 2012 @08:40PM (#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.

  • by DarwinSurvivor (1752106) on Monday January 02, 2012 @08:42PM (#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.

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

  • by Chuck Chunder (21021) on Monday January 02, 2012 @08:53PM (#38567964) Homepage Journal

    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.

  • by Vellmont (569020) on Monday January 02, 2012 @09:18PM (#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.

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

  • by nahdude812 (88157) * on Monday January 02, 2012 @09:22PM (#38568244) Homepage

    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.

  • by Thiez (1281866) on Monday January 02, 2012 @09:33PM (#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:What the Fuck?! (Score:4, Insightful)

    by MrMarket (983874) on Monday January 02, 2012 @09:34PM (#38568328) Journal
    Thank you. This thread is a pos if you are interested in learning the topic. This is why people hate nerds.
  • by nahdude812 (88157) * on Monday January 02, 2012 @09:34PM (#38568332) Homepage

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

  • by TubeSteak (669689) on Monday January 02, 2012 @09:38PM (#38568354) Journal

    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.

  • by fyngyrz (762201) on Monday January 02, 2012 @09:43PM (#38568394) Homepage Journal

    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.

  • by Anonymous Coward on Monday January 02, 2012 @11:00PM (#38568878)

    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.

  • by TheEmperorOfSlashdot (1830272) on Monday January 02, 2012 @11:09PM (#38568930)
    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."
  • by spike2131 (468840) on Monday January 02, 2012 @11:52PM (#38569162) Homepage

    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.

  • by Alex Belits (437) * on Tuesday January 03, 2012 @12:41AM (#38569326) Homepage

    The only problem is, there ARE people named Bobby Tables [xkcd.com]. "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.

  • by b4dc0d3r (1268512) on Tuesday January 03, 2012 @12:51AM (#38569368)

    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.

  • by Pieroxy (222434) on Tuesday January 03, 2012 @02:43AM (#38569790) Homepage

    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.

  • by Terrasque (796014) on Tuesday January 03, 2012 @05:32AM (#38570308) Homepage Journal

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

"Your mother was a hamster, and your father smelt of elderberrys!" -- Monty Python and the Holy Grail

Working...