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

[Anonymous Coward]

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

[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

[KevMar]

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.

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

[Anonymous Coward]

It should (almost) never happen on internal networks, since they shouldn't have multiple routes from one node to any other.

Re:Web Applications aren't different

[DogDude]

No, I think you're being a bit silly. No company is going to pay a developer to re-invent IP filtering and firewalling in every internal app. That's a massive, unnecessary expense.

Re:Web Applications aren't different

[achlorophyl]

most vectors are inside any tech assortment can give ou a secure rig but one faulty insider with thte root account or any account, really or within reach of certain racks, certain cables unless you go full co-lo at expedient for example where nothing short of a nuke attack will take out your system that is the type of cloud to roll we all get good grades but who will take out your network?

Re:Web Applications aren't different

[chrb]

You probably shouldn't trust your Intranet - there are simply too many ways for a hostile attacker to connect to your network (e.g. open or hackable wifi, ethernet etc.), and you probably have no worthwhile authentication (MAC addresses can be spoofed, most DHCP servers will hand out an IP to anyone,...). Trusting your intranet also means that, if a single machine on your Intranet is compromised, then your trust circle is broken. Note that recognised security expert Bruce Schneier uses an open network. As he said, "If I configure my computer to be secure regardless of the network it's on, then it simply doesn't matter. And if my computer isn't secure on a public network, securing my own network isn't going to reduce my risk very much."

Re:Web Applications aren't different

[chrb]

The problem is not limited to the server trusting the client. The problem is that the client side user *has* to trust the client. Web applications are obviously a subset of all possible client/server types. They are slightly different in that they enforce the use of certain protocols - HTTP, HTTPS, HTML. Your client is a standard web browser. Some people would argue it is harder to secure such a setup than one that uses a custom client, because you no longer have the default choice of a server-side stateful protocol, and because you have to serve HTML (as opposed, to say, restrict the client API to some kind of big-endian bytecoded packet based protocol). Problems like XSS only exist because your client is a standard HTML web browser. Apart from that, you are also exposed to all of the potential bugs in the various platform web browsers, because your "client" is also used to browse random porn sites etc. A custom client, used only for the purpose of connecting to your custom server, does not have this issue of having to deal with data from any old random site on the internet.

Re:Web Applications aren't different

[naasking]

The vulnerabilities web applications present are in fact very different. You won't find CSRF or clickjacking attacks in many other domains. There are also many DoS opportunities.

Re:Web Applications aren't different

[Alex Belits]

The difference is, it's usually considered acceptable for networked application to have ABSOLUTE SHIT security because either application is used only between "trusted" clients (all "enterprise" crap with remote GUI, all HPC, networked backup, etc.), or nothing depends on its security (networked games).

Re:Web Applications aren't different

[Anonymous Coward]

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

The only difference between "inside" and "outside" is in your head. In fact, all things being equal, employees are more dangerous than hackers.

You need to assume that any input to your program is evil, and sanitize it to whatever level is necessary to ensure safety.

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

[Anonymous Coward]

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.

Well, the reasoning I have heard is more along the lines of "This particular application, while not something we want to have accessible to the outside, is not the most important thing on the network. If someone can abuse any security holes in this application we have a lot larger problems on our hands since they also can access the important things on the network."
Basically developers don't waste time securing applications that aren't that important. Hopefully the attacker will find the less important stuff first and be busy playing aroung with it instead of breaking into the mission critical stuff.
This will however not help the OP the slightest. If he really needs banking security on the application it sounds like it will be the most important thing on the network.

Re:Web Applications aren't different

[Alarash]

I don't know what kind of layers you're talking about, but in networking, applications are all the way to the top, and then SSL, TCP, IP and so on. In fact I can't think of any case where the application isn't the highest layer.

Re:Web Applications aren't different

[Gaygirlie]

Indeed. The one, single advice I can offer the OP is: be paranoid and NEVER trust any input, even if it comes from within the other computers on your internal network. ALWAYS sanitize input.

Re:Web Applications aren't different

[Anonymous Coward]

Use secure hardware = IBM POWER
Use secure O.S. = A.I.X, z, or i

Re:Web Applications aren't different

[ewanm89]

If doing full mutal auth with client side certificate, as long as it was not compromised at client cert generation time then it's secure as the client cert gets crossed signed by the server cert, if either cert has been changed this will no longer match, CA is now irrelevant in this case.

Re:Web Applications aren't different

[Terrasque]

But you'd never trust ANY client would you?

It isn't quite that simple. How do you know that the POST you just got from the client is, in fact, from the user clicking a button and not from an injected javascript living in the tab with Ye Olde Pornsite loaded?

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

[Anonymous Coward]

The issue as I see it, is that unlike traditional applications, YOU design the interface. Web applications, in contrast, rely on the web browser's security as well (cross-site-scripting).

Perhaps someone needing COMPLETE security would write their own app (WinForms, WPF, SilverLight, Flash, etc) and just expose data services for the app.

Re:Web Applications aren't different

[Anonymous Coward]

*SIGH* , from the general tone of the comment you can CLEARLY see what the guy is talking about.. he used the term "packet" to talk about the tiniest bit of information (Yeah, now go cry over the use of BIT!).

Re:Web Applications aren't different

[Anonymous Coward]

I tip my hat for you sir!

Re:Web Applications aren't different

[fa2k]

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

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.

How exactly would one block users without write access?

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

[Anonymous Coward]

I agree with the analysis on Certificates as far as it goes. The ball game has changed since I first went through Programmer Training at GTE in the early 1980s. Now bastion hosts and DMZ's are not enough, since we are putting out new applications that are themselves the perimeter.

It is important to look at all the layers of security for a defense in depth approach, and really address the attack surface for Web Applications.

The (ISC)2 has a good CSSLP (Secure SDLC ) course that addresses this from the requirements through the deployment of the applications, and at a minimum their book on this is a good read.

It is interesting though, that the OWASP Top 10 vulnerabilities still include SQL Injection, XSS and CSRF some of the most basic security issues, that can be addressed at a "don't trust any client sided data entry" level. There are some issues that are new to me, like Locality of Reference regarding Temporal and Spatial locality that are beginning to be addressed by ASLR (Address Space Layout-Randomization) and DEP (Data Execution prevention)

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.

Re:Web Applications aren't different

[LWATCDR]

Okay how are you going to get a breach of security behind a NAT firewall?
They are going to have to compromise a server "If you have one on your network" and then use that machine for an attack.
Or you are going to have to have your router firewall compromised and the villan setup port forwarding rules to allow an attack on the server.
Depending on the data of course on the server yes you can be a lot less paranoid on some intranet systems than you can be on the web.
I will say if you are dealing with a large complex network then you are 100% correct. You never know when something will be forgotten or someone forwards something that they should not.

Re:Web Applications aren't different

[jwhitener]

How would you write a web app that has methods in place to detect and handle a compromised CA? Or a compromised API, like between your app and Google Apps?

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.

Re:internet explorer

[Anonymous Coward]

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.chase.com/index.jsp?pg_name=ccpmapp/privacy_security/resources/page/online-systems-requirements
http://www.bankofamerica.com/onlinebanking/index.cfm?adlink=&context=en&locale=&statecheck=NY&template=browser_help_and_tips&cm_mmc=&cm_sp=
http://www.usbank.com/cgi_w/cfm/about/browsers.cfm
https://www.key.com/personal/online-banking/personal-online-banking.jsp (they don't list Chrome, but Chrome works just fine)

Re:internet explorer

[Anonymous Coward]

Whoosh...

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!

[Anonymous Coward]

They could always steal your money

Re:EULA baby!

[Anonymous Coward]

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.

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.

Maximum security, unplug the ethernet wire

[youn]

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

Re:Maximum security, unplug the ethernet wire

[hedwards]

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

[Anonymous Coward]

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

Re:Maximum security, unplug the ethernet wire

[mrmeval]

It's:
disconnect it from the net/phone
wipe the harddrive
cast it in concrete
wire it with explosives
bury it in a vault
post armed guards outside
then nuke it from orbit

I added the nuke just to be sure.

Re:Maximum security, unplug the ethernet wire

[HopefulIntern]

Better still, don't build the system at all. If it doesn't exist, it cannot possibly be compromised.

Re:Maximum security, unplug the ethernet wire

[mrmeval]

That was an old meme which in essence states that you can never have truly unbreakable security. It is specific to electronic computing systems but it applies to anything you want to secure.

I believe someone from the NSA gave a presentation on how they never assume anything in any system is secure, that no one is trusted beyond the trust they need, etc.

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

[Angostura]

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

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

Re:Easy answer

[msobkow]

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.

Re:Easy answer

[marnues]

The question was open ended and you are making just as many assumptions as anyone else. The way I read it, he's looking for suggestions on what tech stacks are easily secured, and what design methods keep them secure. The latter has very little to do with tech stack and is more important to security. No framework forces a coder into security. And since the author hasn't had to worry about it, previously used technologies may be completely out of the question. The author doesn't know, which is probably why the question is quite open.

Re:Easy answer

[shish]

a dedicated network as with the banks' teller terminals and ATMs.

I'm not sure ATMs are as segregated as you'd think - a few years ago when loads of XP boxes were getting hit by the worm of the day (code red?), a bunch of ATMs were getting knocked offline by it...

Re:Easy answer

[Anonymous Coward]

Oh simple, just make sure the laws state that all break-ins are the responsibility of the user who's account was compromised.

Simple.

[Anonymous Coward]

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

Re:Simple.

[Neil Boekend]

I prefer an even number, for ease of decryption.

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.

[Anonymous Coward]

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.

[unity100]

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

Re:Filter EVERY input right at the start.

[Anonymous Coward]

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.

[FormOfActionBanana]

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.

[BitterOak]

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.

Re:Filter EVERY input right at the start.

[Anonymous Coward]

That's exactly the wrong way to do it, and why I posted my reply in the first place. You do not check for "known bad input." You only accept "known good input." Attacks change constantly, and there is no way of keeping on top of them. Unfortunately, many naive developers attempt to check for bad inputs, and wind up getting compromised in short order. Again, the correct approach is to only accept known good inputs.

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.

[Anonymous Coward]

Nobody said input validation was the end of the story. Anyone writing code that accepts external inputs and doesn't use prepared statements for database operations is a fool, and deserves what he gets. Please stop making assumptions.

Re:Filter EVERY input right at the start.

[Anonymous Coward]

Exactly. It's like the NTFS file system - it supports file names containing nulls, directory separator chars, etc. Because all strings are "counted" and not "terminated". That's the way all secure software should be designed, IMHO.

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.

Re:Filter EVERY input right at the start.

[strikethree]

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.

If I am understanding your argument correctly, you are stating that a program must try to make sense of any input. I strenuously disagree.

A program should drop/ignore (filter) all data that does not conform to the desired input protocols or data structuring. The issue that you appear to be arguing against is that a person can not be named Bobby Tables. That is plain silly. The issue is the semi colon, not the rest of the name. No legitimate name has a semi-colon in it (currently). If a semi colon is a desired attribute that you would like to save then you either have to change SQL or simply escape the dangerous bits.

Trying to make sense of all inputs is insane. When you type something nonsensical at the command line, what is the result? The result is a message stating that the command could not be acted upon. What would happen if the interpreter was forced to act on the nonsensical command (which is essentially what you appear to be arguing for)? Undefined behavior is the result. This is where exploits happen.

TL;DR - Drop all inputs that do not match the desired format.

Re:Filter EVERY input right at the start.

[Alex Belits]

If I am understanding your argument correctly, you are stating that a program must try to make sense of any input. I strenuously disagree.

No. A program should NOT try to "interpret" data that is supposed to be handled in an opaque manner. It should make sure that data, no matter what is in it, is always handled as just that, data. If it was received from the client, it must be treated as "tainted" -- that is, guaranteed to never appear at the input of any programming language's parser, be it SQL, Perl or machine code. For example, all SQL implementations support some way of declaring statements with no inline data. Use them, and supply data separately. This also improves performance because with proper implementation it reduces amount of parsing that database server performs at runtime.

Re:Filter EVERY input right at the start.

[Alex Belits]

NTFS approach to the data reference/identifiers (what file names really are) is completely retarded because it is made entirely in assumption that such identifiers should contains anything human-readable, and will be handled in an ambiguous manner (the case, languages) instead of merely being human-identifiable names.

Filesystems' approach to data (any number of bytes with any content) is perfectly acceptable.

Re:Filter EVERY input right at the start.

[asdfghjklqwertyuiop]

People's names are not usually "acted upon" like command lines are. As far as the program is concerned, they're just arbitrary character strings.

Re:Filter EVERY input right at the start.

[strikethree]

Fair enough. I misunderstood your argument. Have a nice day. :)

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:An experienced developer? I doubt it

[goarilla]

Funny that you say this; I always look if the key that they typed is close to the one they should have typed, to determine
if it's excusable or not.

There is a book about secure Java programming

[kvvbassboy]

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

[Anonymous Coward]

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

Citation needed.

Re:There is a book about secure Java programming

[DarwinSurvivor]

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

Re:There is a book about secure Java programming

[kvvbassboy]

Yes, but it did have a lot of positive reviews.

Re:There is a book about secure Java programming

[jones_supa]

Try putting "book review" in the Slashdot search box and see if it comes up.

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.

Re:And, minimize damage.

[Anonymous Coward]

He's suggests doing a recovery plan. Having a plan for recovery from catastrophic failure and especially _testing_it_in_practice_ is always a good thing with important hardware and software. Of course also try to mitigate risks where ever possible.

Re:And, minimize damage.

[Anonymous Coward]

Risk mitigation is not hack-proof.

There is no such thing, in this age of 0-day exploits, as an unhackable system. It's just a matter of how much money and how much time do the attackers have at their disposal.

So if it is that critical, there needs to be greater defense layers that just the shell of the application perimeter. The internal systems cannot trust each other, either.

Re:Start with the W3 guide to secure CGI programmi

[inviolet]

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.

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.

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

design in damage control

[Anonymous Coward]

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.

Re:design in damage control

[goarilla]

If it crashes there usually is a (exploitable)(remote) bug.

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

Re:Get IIS 4

[Anonymous Coward]

Follow best practices and common sense (good passwords for power accounts). You need to continually look at what languages are best for any given situation and what exploits are in use for that language - check out the penetration testing site http://www.exploit-db.com/google-dorks/ and make the necessary ajustments to your server software patches or settings.

As well as the advice given regarding ports and firewall rules I would suggest making sure the logs are viewed and full backups taken over a period of a couple of weeks. At least you can restore if things go wrong with the hardware or software. On the networking level I always understood that if you look at other protocols (Novells IPX), aside from TCP/IP then you may have a better chance at security. The real issue becomes how does a server validate another person from a remote computer (authentication methdos). What attack vectors are there for your web server / firewall? The virtual word is no different from the physical here and no fortress is 100% secure. Logs are like virtual CCTV, sentry gards are the IT admins. If they go to sleep are or not looking out then it's easy to get in or sniff other credentials and record those for future use. Just don't ever boast about how secure your site is or you are putting yourself up for a hacking challenge!

Re:Get IIS 4

[Anonymous Coward]

Or just run a 15 year old linux kernel and 15 year old builds of apache, perl, etc.

+5 Funny, right? No?

I fail to see how the parent got modded to +5 funny. There is nothing clever or original about it.

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.

Re:OWASP.org

[Bill, Shooter of Bul]

So sad, that this isn't the first non-troll post. Its the most obvious first place to start. There are more specifics that can be delved into, but if you aren't starting with their guidelines, eck!

Re:OWASP.org

[not-my-real-name]

I would also suggest reading "A Fire Upon the Deep" by Vernor Vinge. It's science fiction, but does actually talk a fair bit about data and communication security and ways of subverting systems. "A Deepness in the Sky" by the same author also covers similar themes.

Re:OWASP.org

[Bill, Shooter of Bul]

I would defintely not suggust taking time reading science fiction.

1) Read OWASP
2) Choose Tools/Technologies
3) Read OWASP
4) Design counter measures for OWASP Top Ten
5) Read OWASP
6) Test Tools/Technologies with counter measures enabled
7) Read OWASP

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

[Anonymous Coward]

Take your own advice first.

Re:What the Fuck?!

[MrMarket]

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

Re:What the Fuck?!

[Anonymous Coward]

We're not nerds, we're pedants. (geddit?)

Re:What the Fuck?!

[datavirtue]

1) Go to Amazon.com
2) Search: Penetration Testing
3) Buy two or three books for $5 or $6 each
4) Get plugged in to the security community online

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

I was just thinking about that!! 5 gazillion comments and maybe 3 or 4 answered the question...

What's wrong with people out here ? One thing is answer the question and then make some comment on the subject, another totally different and unnecessary is talk shitloads of "listen to how I know what you don't... moron."

Such inflated egos!!

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.

Re:Be paranoid (trustno1)

[Matheus]

I do a lot of this in my code just for the sake of writing solid code (not necessarily just secure). The number of times I've said to myself whilst coding some seat belt "This is an impossible case but the code will break if it were to magically occur so the seat belt stays." Add a little logging and oops... my typo over here caused a weird flip over there and the impossible occurred but wasn't able to crash the system because of a proper seat belt. Make what I'm writing a library / anything utilized by someone else (user input) and it never hurts to be over cautious.

Re:Be paranoid (trustno1)

[dropadrop]

Also, if using an object oriented language try storing user provided input in objects rather then passing them around as user provided (and maybe filtered) strings. That way if there is a problem with some variable somewhere you might only have to fix the setter / constructor of the class instead of having to search around for countless places accessing the input data directly.

Re:Be paranoid (trustno1)

[mattpalmer1086]

Encrypt whatever you can, whenever you can.

Most of your advice is solid, but this bit isn't. Encryption is hard to get right, you have to deal with key management issues, and it can give a false sense of security. For example, many inexperienced people encrypt data because they want to prevent users modifying session state - it's encrypted, so it's secure, right?. This is a mistake, as encryption only serves to protect the confidentiality of information; it does nothing to prevent modification, or replay of earlier information.
    Applying encryption "whenever you can" is only a recipe for an insecure application that merely looks secure to novices.

You should design your app so that as little information as possible needs to be encrypted or otherwise protected in the first place. Minimise the amount of information that is actually required to be secured, and minimise the cryptographic secrets you must maintain to achieve security. But get someone who understands cryptography and security to do threat modelling and work out a good security architecture.

Hire someone.

[Anonymous Coward]

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

[Anonymous Coward]

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.

Business sense

[Sepultura]

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.

Re:Business sense

[mSparks43]

Hmm, yes but.

"secure by design" requires strong security built in from the start surely?

Will save a fortune later on "hardening" if it is designed well from the start.

Something i've been playing with for a while is the honeypot idea.

Basically, lock everything important behind everything you can think off, wall after wall after wall. But then at the webserver end stick a non hardened honeypot - with shed loads of intrusion detection built in.

Then, any IP that drinks from the honeypot gets a network wide ban (I catch 5 or 6 IPs a month from malformed URLs alone).

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.

Re:not only prevent, but also mitigate

[Anonymous Coward]

While one can arguably say everything can be hacked (unless air-gapped)...

Iran's uranium enrichment centrifuge controllers were air-gapped. Stuxnet destroyed the centrifuges anyway, by first:
* spreading benignly to a large proportion of Windows machines worldwide, exploiting no less than six (6) zero-day holes
* eventually spreading from USB thumb drives that workers carried into the facility onto the control computers
* from there, directing the Siemens PLC controllers to run the centrifuges faster than their rated max speed, while faking sensor outputs to make everything appear normal until it was too late

As OP said: EVERYTHING

Re:not only prevent, but also mitigate

[Anonymous Coward]

* eventually spreading from USB thumb drives that workers carried into the facility onto the control computers

No, assuming that's all correct, then they failed to properly secure the air gap.

- T

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

[Anonymous Coward]

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.

Re:Layers

[jbolden]

I was saying vulnerability assessment above. VA (IMHO) is very specific to the choice of tools. But I agree it is a critical part of the process. Humans can check some stuff in detail but they don't check 50,000 easy things.

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

[ark1]

+1 for multiple layers.

If this is a serious project, you should definitely consider getting a security pro involved to conduct a proper risk assessment. This will give you a good idea of what will be required to meet security expectations throughout the entire life cycle of your system.

Physical security, Network security, Policy/Legal requirements etc will likely require to be assessed if not already done.

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

[Anonymous Coward]

so you're buying "languages, servers, software" with a "security aware" sticker?
and you don't "want to set permissions"?

Sounds like another of these "security experts", that is, your points are remotely correct but it sounds like you don't understand them. so most of the points have correct AND incorrect input.

- layers are good, but that's actually compartments, sandboxing, etc. It's called: separation.
"hostile" is actually called "attacker" and "g yoing through the architecture" is in fact "list all attack vectors"

- you *want* to use permissions. yes, you should have a minimal target, that is, don't use features you don't need, don't use features that are not secure by design. but you'll still need permissions. they don't specially need time to setup, because, it's only relevant to the software you use, "permissions" if a very, very generic word.
In fact, I suspect you don't understand your own sentence.

- no. just no. you don't get stuff with a "its secure" sticker. what you hopefully mean is that you want to use languages that offer bound checking and the like.
frameworks don't just "check all the things! and we're secure!" every single framework has bugs and only a few things can go through specific parsing checks (and that's INPUT and OUTPUT. You need to be able to define what goes in and what goes out and check on that. It can be POST, GET, but it can also be an URL and so on.) Note that most frameworks do this as best they can nowadays.
There's also no database that "checks stuff and make them secure". None. Maybe you mean using prepared statements when using a SQL database.

- yes, the network needs to be "fragmented", but the word here is again separation. Run different things on different system and give only access to what's necessary. Run them in different networks when possible.

- there's nothing "you are going to want" unless someone is trying to sell you a product. Network IDS just recognize patterns, and unless you have a guy setting it up and monitoring it full time they're not efficient, at all. Host based IDS are a little more helpful.
Vulnerability scanning is generally used by companies who can't afford to update everything to latest, or aren't easily aware of what's running.
It's better to be up to date and to know what is running. If you don't know what's running, you already lost.
Now that doesn't mean it is useless, it's the way it is presented that is. The scanning should still take place if you can afford it - but it's generally a paid service as people need to compile new vulnerability lists constantly. This allow catching potential things you can potentially miss, or give an external point of view on system scans (as in network scanning/app scanning).

and the last thing nailed it for me. if you're not able to explain what you are supposed to do with anything else than buzzwords with zero insight, why should someone hire you (on slashdot too!). Sounds pretty desperate.

What the guy asks for, is actually insight to make educated decisions. You're not offering that.

Re:Layers

[jbolden]

You are an AC but just in case someone is confused by your comments, you sound like someone who knows a limited number of approaches.

1) I meant capabilities (http://en.wikipedia.org/wiki/Capability-based_security )
2) I didn't say "list all attack vectors". I recommended a specific approach to avoid having to make that sort of comprehensive list. Listing all attack vectors assumes you already know a great deal about securing your system.
3) There is far more than just POST and GET. This isn't 1996 and he isn't necessarily using CGI for the application.
4) Of course databases do checking. At the most basic level: http://en.wikipedia.org/wiki/Relational_database#Constraints . Beyond that capabilities are important, if data is coming in tainted it can only be read by subsystems which are designed for tainted data.
5) As for the network, I absolutely want fragmentation not separation. I don't just want distinct subnets, but subnets where the majority of machines are non-addressable from the other side.

What the guy asks for, is actually insight to make educated decisions.

No, read the post. "I am clueless of what is requires to create a web server that is as secure as, say, a banking account management system" I gave him a list of what is done. And the first thing is if he is clueless, he shouldn't be the one making the decisions he needs to bring other people onboard.

Re:Layers

[Enleth]

The key, I think, is "properly". I've seen some deployments (none as big as yours, to be honest) that started off similar to that, but as changes went on, security measures went away or were literally worked around because they (obviously) slowed down the development process. The result was a total mess, neither secure nor efficent.

I haven't really had a chance to ever go totally mad with security, but if I somehow get it, I'm sure going to try all of those things listed in the previous post and much, much more.

Re:Layers

[jbolden]

I always tell people good security quintuples the cost. If they still talking then we are going to get all the way through. If they were thinking more like an extra 10% then we start looking at a few gimmicks to get a cheap boost and forget doing it right.

Niche Setup

[Anonymous Coward]

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

[bleedingsamurai]

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

[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

[Jaime2]

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.

Earthquakes don't adapt their attack strategies as well as hackers. Learning to hack will help you harden against the lamest attacks of five years ago. Every single buffer-overflow can be fixed by simply keeping up on patches. Every SQL Injection vulnerability can be fixed by using a proper database access layer.

I find it much more effective to first apply basic coding standards based on OWASP, then to think of every web page from a request-response perspective instead of from a user perspective. 90% of the stupid security coding I've seen came from somebody who never considered that an attacker doesn't have to be using a standard web browser. Once you get over that hump, there is no value in learning all of the script-kiddie tricks.

I also find that security professionals often lack perspective. I once had a security guy go into great detail showing me how a page was vulnerable to cross-site request forgery and replay attacks. I told him "It's a catalog page, I don't care who reads it. It's URL-parameterized so that my customers can email links to each other. In other words, I'm counting on CSRF for sales.". The funny part is that if I had used URL rewriting instead of a query string parameter, he wouldn't have even known the feature existed.

I am a firm believer that security belongs in the application team. Engaging an outside expert tends to send the message that it's somebody else's responsibility to do security. In reality, security is everyone's problem.

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.

Re:Learn to break them

[kangsterizer]

it depends what security experts do. i don't know many experts that spent a lot of time in school. it doesn't even really matter as most work on stuff at home too and always did so anyway.

the best experts i know are typically your ex hacker, however cliché that is. that's because it's different when you attempt to "just break software" following instructions, and being in front of the problem without any limitation.

a hacker, as in a guy attacking and compromising hosts has indeed no limitation. he has a target and he has to compromise it. those guys are generally creative and have to think outside the box all the time.

again, that' a different mindset than having a list of rules or checkpoints, or following a "how to buffer overflow xx" and attempting to do it yourself, or "how to unpack program ZZ" and attempting to unpack a program yourself. the later is useful, but it's still the wrong mindset.

Some tips

[Bucky24]

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

[mortonda]

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

[Bucky24]

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

[mortonda]

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

Re:Some tips

[Anonymous Coward]

. If you're super good at programming clean secure C/C++ you might want to program your own webserver.

Do not do this!

Coding your own web server opens up a whole new bag of issues. While apache and co aren't perfect; nobody is going to write a perfectly secure webserver on the first shot either.

Re:Some tips

[Jaime2]

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

That's the worst idea I've ever heard. Apache and IIS both average less than ten discovered meaningful vulnerabilities per year. Making a secure HTTP server is way harder than you think it is.

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

Look up Cross-Site Request Forgery, it's a whole class of attack that makes the browser do the hard work for you. This is a great example of a case where using a framework instead of rolling your own is best. Most authentication frameworks had some CSRF protections in them before most web developers even knew it was a problem to be worried about (for example, marking session cookies as HttpOnly).

Re:Some tips

[Bucky24]

That's the worst idea I've ever heard. Apache and IIS both average less than ten discovered meaningful vulnerabilities per year. Making a secure HTTP server is way harder than you think it is.

Yeah you're probably right. I just think it would be a cool idea... Probably not a very secure one though.

Security Engineering for Distributed Systems

[FormOfActionBanana]

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

[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:You give banks too much credit

[devadraco]

I think you give security audits too little credit. In a security audit or vulnerability assessment, auditors or penetration testers have to work within a scope of work predefined by the project management. In most cases of missed security findings, it's due to insufficient coverage of the scope. There's no free lunch, and no one's going to do extra work for free. Furthermore, a lot of security holes found are rejected by the business owners. What's a consultant to do when a client refuse to accept a finding?

Re:You give banks too much credit

[Tony Isaac]

You are exactly right. For the very reasons you listed, security audits often fail to uncover real security problems that exist. A comprehensive and competent audit requires a lot of money, a lot more than most companies or local governments are willing to pay. And that is precisely why I put so little faith in audit findings.

Comprehensive with layers FTW

[Anonymous Coward]

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.

-Ryan

Back to basics

[thogard]

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.

_The Tangled Web_ by lcamtuf

[Anonymous Coward]

http://lcamtuf.coredump.cx/tangled/ Don't even think of building any non-trivial webapp before reading it.

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.

Start by eliminating low-hanging fruit

[93 Escort Wagon]

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.

Re:Start by eliminating low-hanging fruit

[Skapare]

Or just use NoSQL.

Re:Start by eliminating low-hanging fruit

[Anonymous Coward]

you idiot

Re:Start by eliminating low-hanging fruit

[Anonymous Coward]

The bit about not using PHP is utter rubbish. MANY years ago, PHP was riddled with quite a few easy-to-exploit security issues, but that hasn't been the case for a long time. The company I work for has customers in every single state in the US plus several countries in Europe, and the websites have several hundred thousand unique visitors every day. It's all built in PHP with some Perl handling background tasks.

There hasn't been a security breach due to PHP since I've arrived at the company - and I've been there for five years. (Actually, I can't remember the last time we've had a security breach of any kind originating from an external source - but that's besides the point.) We have lots of information people would be interested in as well - email address, mailing addresses, names, cable account numbers, etc., etc., etc., plenty enough for spammers and identify thief types.

It doesn't really matter what language is used as long as it is relatively mature and you have someone competent doing the development. That means someone experienced in the language of choice that understands the nuance - and every single language in the world has nuance.

You are clueless as well.

[Anonymous Coward]

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.

Complexity, Time and Money Prevents Good Security

[CodeBuster]

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 for breaches of protected health information. As soon as breaches go straight to the bottom line companies start caring.

Mod parent up

[Anonymous Coward]

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.

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

[Anonymous Coward]

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.

FINALLY!

[Joe U]

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.

Re:FINALLY!

[jbolden]

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.

Re:FINALLY!

[Joe U]

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

[jbolden]

Whitelisting is a pain in most languages and a lot of work. That's why I'd go with languages and/or frameworks that make it mandatory and easy. But fundamentally most developers don't like doing security, that's why it is often a good idea to have a security development team do work like validation of input functions and then the more application oriented stuff is done by developers.

Re:FINALLY!

[kangsterizer]

Isn't that the basics? Everyone knows so since forever.

you nailed the issue "theres always a shortcut to save time or money" (actually its time and money, time *is* money ;-)

there's no point having a secure app if it's not going to sell. making money is more important than being secure. it's all about balance, aka making money while being as secure as possible. some achieve better balance than others.

To be as secure as a bank ...

[Skapare]

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

Re:To be as secure as a bank ...

[Anonymous Coward]

avoid apache? plz

Re:To be as secure as a bank ...

[swalve]

I think the idea is that it is too big and too popular to be super secure. Using a smaller app as your webserver reduces the surface area for penetrations, and a more obscure one will not have as many people exploiting it. A small, stupid server is easier to harden.

Well...

[stevenfuzz]

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.

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

[stevenfuzz]

Explain this to Sony and Citybank.

A Good Book - The Tangled Web

[NaCh0]

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 by Michal Zalewski.

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

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.

owasp

[Anonymous Coward]

follow that and you should be alright.
https://www.owasp.org/index.php/Main_Page

Validate your inputs!

[SplashMyBandit]

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.

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.

Just Validate

[Anonymous Coward]

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.

Re:Just Validate

[swalve]

Also, don't expose anything that isn't necessary to the outside world. Make sure anything you send to the client doesn't contain any information besides what is absolutely necessary. No hints as to what is behind the scenes.

Re:Start with the W3 guide to secure CGI programmi

[mSparks43]

Yeah, I also like the "Red Black" concepts and wikipedia has quite a nice article on
http://en.wikipedia.org/wiki/Secure_by_design

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

[Anonymous Coward]

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

Benchmarks

[Anonymous Coward]

The following should help set you in the right direction
http://benchmarks.cisecurity.org/en-us/?route=downloads

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:Secure Programming book

[Raenex]

Seems that Slashdot is bogging down your site. Alternate site: http://tldp.org/HOWTO/Secure-Programs-HOWTO/

You're doing it wrong...

[supermonkeycool]

Unless you are like me and use electron-level encryption. Shit is encrypted before it ever becomes a bit, much less a packet in some hacker's wet dream. Fire up your SEM and get with the program. Pussies.

Don't trust anything, don't trust anyone.

[Lord Juan]

That is about the best advice that I can give you, treat every single piece of data that comes from the outside world as malicious input, if you can validate against expected values or patterns, do just that, and discard anything that you aren't expecting.
Once an user is logged in, do not trust them, at all, be very careful with privilege escalation.
Use prepared statements for every single data that interacts with the database if this data leaves your control even for one operation, it doesn't matter if it comes from direct input, from a session variable, from a cookie, you check the data and use prepared statements ALWAYS.
Keep your software updated, if you need this to be secure, you can't just make one installation and feel good, you will have to be prepared to constantly update the software in the server, and there will be no end to this as long as you want a secure platform.
Protect the passwords in the database in case they are stolen, a hash+salt per password is an option to do this.
Security is not about preventing a hack, it is about reducing the chances that a hack occurs. If you have valuable information, you will get experience attacks, and you have very valuable information, you will eventually get hacked, you have to find every single hole in the software, the attacker only needs to find one.

Re:Don't trust anything, don't trust anyone.

[Lord Juan]

ok, a hash+salt is not an option to do this, maybe it was at some point, but it isn't atm =/, the rest of the advice do applies tho.
http://codahale.com/how-to-safely-store-a-password/

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

[Anonymous Coward]

And then there's social engineering

Well, yes. But that only works against idiots.

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

@gman003 plus

[Anonymous Coward]

Do all the things @gman003 says and always work on a live code. Don't put anything for three weeks and try to integrate later. Involve testers from early in a project. Since it is your internal project, there must be dedicated testers. Build small and functional code from the word go. Don't focus on too many things. Build one logic and build it completely, so that you theoretically don't have to visit it again. Less is always good. Thinks twice before you write some fancy feature. More code, more debugging, more responsibilities, more problems. Take time to think before writing code (this sounds like insult, but the greatest advice I got). Can you (and nobody else) can trace the program (code) from beginning to the end. If not you have a problem of being inserted foreign code or malicious code in the project. Log every exception into a file. For some months even log Logger.info into clients computer. Everything else is taken care by your well tested security framework. One thing about security (being a guy who developed intrusion detection system), it is how fast you act after a security breach decides how secure your system is,not how secure you write a code. Any system given 24 hours for an expert cracker is almost always breakable. Its not only software that is the whole system, it is the people who service it, use it and try to break it are part of the system.

Meet my friends Greasemonkey, TamperData, and SQLI

[Proudrooster]

In order to understand security, you must first understand how to hack or abuse a website. I recommend spending at least a week as a hacker. Here are some things to get your started:
1. Install Firefox or Chrome, I like Firefox for webdev.
2. Install GreaseMonkey https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
3. Install TamperData https://addons.mozilla.org/en-US/firefox/addon/tamper-data/
4. Learn about backend resource management and data validation, specifically SQL Injection. http://hackthissite.org/ is a great place to start
5. On your backend database ENCRYPT all sensitive data, names, account #s, social security, birth-dates. I like to encrypt all the fields then use an off-by-one Fibonacci encoding for numeric fields, so even if you are hacked/decrypted, this is still one more layer of encoding. So many fools do not encrypt their database field data and get owned by SQL-injection attacks or sever compromise. The list is long and distinguished.
6. Lastly, if you are running standard open-source packages test your site for cross-scripting vulnerabilities.
7. Web server lockdown depends on your server and platform Apache, IIS, Windows, Linux... but LOCK IT DOWN!

Also, don't do obvious things like put sql connect userid/passwords in your backend scripts especially if you are running a VM on a shared hosting server. Close down all unused ports/services on your server. Never trust the frontend firewall especially if it says CISCO on the front. Run tripwire. Run MRTG with Big Brother and monitor your traffic/activity and always keep an eye out for anomalies. Keep an eye on your logs and do daily backups.

There are hordes of hackers around the world looking to build backdoors into your site, especially if you have bandwidth and storage. Too many folks (including the new cloud guys like Amazon) have no baseline for activity on their system, get hacked, and are clueless.. maybe that is too harsh, I will say mostly clueless but getting better at responding.

If you need further help, I am available as an extremely expensive consultant, but I am slammed with work at the moment. Good Luck and remember the Internet is an extremely dangerous place.

my minimalist approach

[Anonymous Coward]

keep it simple stupid.

i don't develop banking websites, but i take security reasonably seriously.

1. don't use windows for any type of server (use linux). fairly self-explanatory, if inflammatory (lots of shills on /.)

2. install stable release of a reputable linux distro (i use debian squeeze stable)

3. remove all the crap (gnome, network manager, mono, etc)

4. harden your stack configuration per distro docs (paranoid iptables, hosts.allow/deny, shell=/bin/false in /etc/passwd, no inet.d, no ssh, no sudo and wheel group for su, disable as much as possible in php.ini, no mod_proxy, 403 default vhost, etc). there's a lot more than this but i've just put some that i can remember off the top of my head. back up config files to a couple of CDs.

5. use a raid1 storage (i use a 4 disk hotswap nas with nothing but nfs on an isolated lan). i know nfs is insecure, but as long as your iptables is locked down should be ok on a separate network

6. don't use any of those json, ajax etc frameworks if you can avoid them. don't use phpmyadmin or any other web management interface (i get a lot of snoops for stuff like this in my default vhost access/error logs)

7. assume all input has been created with a dodgy version of your webpage (someone downloads the page, tinkers with the html and then posts using the doctored version). use a whitelist approach if possible, or if you must use a blacklist approach (often unavoidable), try to research as many of the possible hacks as possible (sql injection, xss, etc). blacklisting "0x" and ";" can often cause headaches for users depending on your app, so filtering can sometimes be tricky. try to code it yourself using guidance because its better if you understand completely what is going on (I think).

8. use openSSL with SHA512 from your own root certificate authority. supply the public key to your customers by post (on CD) with some official company letter.

9. do ip range filtering, referer filtering, etc (even though these can be spoofed in a request header), but it all adds up to more work for the attacker. i tend to also block search/cache bots since seo is not a requirement. if customers can only get to your site by typing an address it means they are less likely to get fried by phishing attempts.

10. if your the savvy type, try hacking your site with the common scriptkiddy attacks. if you can cover those your odds of getting pwned are limited to the more experienced hackers that are more specific in their target selection

11. never stop thinking about security and revieweing the measures you've taken. keep on top of current events on slashdot. find out what new attack vectors have been discovered. keep your software up-to-date (but don't use unstable/experimental versions). don't assume that your totally secure

that's about all i can come up with over a lunch break. no doubt there will be more things you can do, and my methods may draw some criticism, but i'm yet to be hacked and my logs are full of all sorts of nasties so i don't consider myself to be completely ignorant.

good luck

crutchy

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

[TheRealMindChild]

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

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

[devleopard]

Reading is a wonderful thing. The poster asked for resources to learn, which is how one acquires the knowledge you're referring to.

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

[achlorophyl]

client-server applications are a joy to write. As for choice of OS, I would recommended Greater Security Linux or Security Enhanced Linux. firewall technology is the gaurdian of all your knowledge. Learn to roll your own kernal and write IPtables scripts to create a custom network interface learn to lock down every process _bit_ of your system your drive should have every bit _process_ accounted for I would write nothing bad about Linux Most server-side solutions are Linux Apache webservers most people do _not go with MS Windows. Most peple do _not go with Mac OS. Ubuntu's "hardened Ubuntu" is SE Linux. Go with the best you know...

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:Web Application Firewall

[natetron]

WAF is only as good as the regex rules and quickly fall over if you have a non script kiddy playing with you. For example watch how many block sql injection of 'or 1=1' but miss 'or 2 not like 3'

Re:Web Application Firewall

[breun]

Mod_security is great. I recommend checking out Atomic Secured Linux, which is a product comprising a hardened Linux kernel with trusted path execution, PaX and grsecurity, ClamAV, mod_security, mod_evasive, OSSEC, rkhunter, SSH hardening and comes with continuously updated custom rulesets for its components. It can do geoblocking, active response based on security events and comes with a web interface for management. No, I don't work for them, I'm just a happy customer. https://www.atomicorp.com/products.html Now, of course, having good system-level security doesn't mean it's not important to keep security in mind when building a web application, but the additional layers of security definitely help.

Re:Web Application Firewall

[Terrasque]

a product comprising a hardened Linux kernel with trusted path execution, PaX and grsecurity, ClamAV, mod_security, mod_evasive, OSSEC, rkhunter, SSH hardening and comes with continuously updated custom rulesets for its components. It can do geoblocking, active response based on security events and comes with a web interface for management.

Woah, that's like the digital version of More Dakka

default deny everything

[Anonymous Coward]

default deny everything.

it's that easy.
http://www.ranum.com/security/computer_security/editorials/dumb/

client-server on the server

[dindi]

You can build a client-server architecture on the server. E.g. a SOAP server with the DB connection and a SOAP client+web on the visitor facing side.
You will need security on the outer edge too, but you gain an extra level of security by separating the outer edge from the DB. This way you can also handle security where you know: server application (SOAP).... this could be C, JAVA, PHP, whatever else you want, while the web can be HTML/JS/AJAX with or without PHP.....

You can also scale by adding more clients or servers based on loads ..... of course you cause an overhead this way ......

Application security

[bl968]

It's simple never trust the user. All inputs must be checked and sanitized.

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.

Re:Start with the W3 guide to secure CGI programmi

[achlorophyl]

SE Linux: NSA's security enhanced Linux Understanding the Linux Kernal Understanding Linux Networking Internals The Linux Programming Interface Linux Kernel Development The Unix/Linux System Administration Handbook this will get you thinking!

Rails

[Anonymous Coward]

Ok I'm sure people will flame me for this one but in my case it's what saved me on an SNS app. I hired a developer who claimed to have written many secure web apps and, knowing I knew nothing about them at the time I didn't want to try it myself. Se he write this app in PHP and raw SQL, he makes some progress and we can start using it from our front end app (which I was working on). I knew about injection, and just as a test I tried it. It went right through. I told the PHP/SQL guy and he called me a liar. I pulled up the records I'd manipulated through the injection and he still called me a liar.

I fired him and a week later out of pure luck met a Rails developer who helped me set everything up in a Rails app, which has built in protection and easy to add-in extensions for OpenID login etc. In another week I'd written a crude Rails app that was basicllally just a login adapter and passed everything else in JSON through HTTPS to our front end app. It's still running and we've never had any security issues. I'm not claiming Rails will make your apps secure or that it's a panacea, just that it helped me out of a bind when I was in a similar position to the person asking the question here.

Re:Start with the W3 guide to secure CGI programmi

[achlorophyl]

with a computer science background, you can make a secure node. The real challenge is making this secure node the cornerstone of your strategic planning -- defense _and _offense

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:The question was, "What should I be reading?"

[Chuck Chunder]

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.

Sure, but then you suggested that he needed to look no further. Additionally the page you linked to only sought to address some application level coding related issues. It didn't even mention other aspects that should be considered (OS configuration, Network Infrastructure, segmentation and other additional layers of defence such as WAF usage etc, etc, etc).

That's not good evidence for your position that the question "continually needs to be asked

On the contrary, the page specifically warns against using the "top 10" as anything other than a starting point for the uninitiated. As it notes, "Don't stop at 10".

Re:So your intranet apps aren't secure?

[aztracker1]

Security is a relative concern... if writing a hardened application will cost 5X as much and be well unable to budget for, you're saying it should't be done at all?

Tips from a "security guy"

[Anonymous Coward]

Any hacker has more time than you do as a developer, so in the arms race of hardening versus hacking, you lose if you try to do it all yourself. The best thing you can do to make a secure web app is to let the code you personally write have as little exposure as possible. Take advantage of years of bug fixes and use a well supported open source monolithic web app framework. My favorite is Django, but try others (Ruby on Rails) and see what you like. You may at first see them as a hurdle to jump over, but you'll eventually come to realize they save a ton of time. (and are secure!)

Other quick tips:
* Never parse data yourself. Use a library. For instance when parsing json encoding, use a json library -- don't be tempted to make your own "quickie" function.
* Any user input that is later printed (a name, for instance) needs to be sanitized by removing HTML escape characters. Most frameworks have a built-in function for doing this. Find a well tested existing function; don't make your own!
* Never concatenate user strings into a database query. Instead use the database's string formatting functionality, which will sanitize the input of database escape sequences.
* Never assume HTTP args are right, even if your app sent them to itself.
* If you're using AJAX, there are complex security risks, so read into XSS attacks.

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

[Anonymous Coward]

I like your attitude; you're promoted!

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

[Anonymous Coward]

Basically, upholding system security is like the flu shot which upholds immunity response for the vulnerable yearly. Our immune system is trained daily. Perhaps our code and other systems should too.

Give up now. If you believe there is ...

[Anonymous Coward]

If you believe that you are going to create a website that will be un-hackable tomorrow then you're doomed. Fine a new career. The best you can do is read, read, read, then rewrite, rewrite, rewrite, hire outside sources to test your sites, and repeat.
And if that isn't enough to do in a week, remember you have to do all of that again next week.

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.

Ask Slashdot: DIY Heart Surgery?

[Tumbleweed]

I'm wanting to do my own heart surgery. Can the Slashdot community recommend good websites, books, or any other resources that thoroughly discuss the topic of doing my own open heart surgery that is as painless as possible?

Was that too subtle? I think I might've been too subtle.

Don't use non-randomized hashmaps ; )

[Anonymous Coward]

OWASP is your friend but basically you'd need common sense. More than what most webapp servers developers have that said.

Out of the stupidest things I've seen in 2011 where: using floating-point numbers API to parse numbers that, by the spec, were required to be between 0 and 1 with at most 3 significants digits. Someone found a bug in a famous floating-point number parsing method and KABOOM! Remote DoS working on every single f*cking webserver using that software (Apache Tomcat for example). Not to mention the extremely inneficient inherent lameness in parsing such a trivial thing with floating-point numbers, but whatever..

That was in february.

In december we've had a shitload of PHP, Ruby and Java webservers out there owned by an hashmap attack. A single XOR would have fixed the issue but, no, hashmaps API designers thought non-randomized hashmaps were a Good Thing [TM] (silly dorks they are no?).

But your question proves you're on the correct path: most programmers do s*ck fat balls at programming robust software because they don't realize that it's a harsh world out there, with low-life by millions trying to pirate and break havoc.

Oh yeah... in 1997 or so there were already website cryptographically signing URLs (making sure low-lifes weren't messing with the GET/and-some POST parameters).

People are only starting to "understand" why this is a good thing today.

I pitty you, the road is going to be long. But by all mean do it: it's not hard to beat the crap that is out there.

BCrypt is great, but so is Drepper's SHA2 Crypt

[jonabbey]

These days, you do have a quite reasonable alternative to BCrypt available as well, which is Ulrich Drepper's SHA2 based Crypt scheme. It's functionally the same as BCrypt but with the use of a different basic cryptographic operation. Like BCrypt, Drepper's sha-crypt is designed to be as slow as molasses, with the ability to make the operation even slower if you like by explicitly specifying the number of SHA256 or SHA512 passes to perform.

Drepper's SHA256 and SHA512 based Crypt routines are now standard in glibc on Linux, as well as on Solaris and HP-UX, and are likely to natively be supported by PHP and the like on those platforms. If you're looking for an implementation in Java, we have one at ftp://ftp.arlut.utexas.edu/java_hashes/.

Re:Start with the W3 guide to secure CGI programmi

[achlorophyl]

and Linux Firewalls

Process and Practices

[Anonymous Coward]

Ive seen a lot of comments talking about input validation but it's not enough. User input validation is not the holy grail of security. Here's my short list of things to think and read about to get you started:

If you dont know what Cross Site Scripting, Cross Site Request forgery, SQL Injection (actually any kind of input injection), buffer/request splitting, timing attacks, corruption, reuse, (and many other such attack vectors), then hire a professional to train you on todays web security landscape so you understand the major attack vectors in use today and how they can be most commonly mitigated. Make sure they explain to you what the limits of technolgoies like SSL are - what they should be relied upon to assert, and what they cannot assert.

Never use user input to take actions across security boundaries. Validating user input is easy - you know what your system expects, but its not enough. For example - dont load a specific file by constructing the path to the file from user input - you might expose yourself to canonicalization attacks. Instead use a hash to lookup the file path that your system knows and key off the file name the user provided. Whitelists are better than blacklists, etc. There are many and numerous traps you can fall into; too many to list here. You'll need to do a lot of learning / hire an expert to get you going.

Knowing and following a security process and security practices is essential to sustained/maintainable secure software development. For example - threat modeling early in your design to understand the interactions in your system and the assumptions each interaction is making. The outcome will result in specific mitigations that must be implemented to maintain security and it will inform you about constraints you need to place on all developers writing code in your application/server to not impair security. You also need to put to memory and insist on basic security practices like least privilege or obscurity is not security. Sticking to security processes and practices will make you uncomfortable at times because it WILL take MUCH longer to implement the software the right way, but the benefit will be more secure system to start with. In the end you'd have to spend much greater effort defending an attack or explaining what happened to your customerâ(TM)s sensitive data.

Meticulously review your system - not just your software, but the entire environment it works in. Ideally have a 3rd party assigned in your organization who is responsible for reviewing security (and know what they're doing), signoff on your work before you release. Fresh eyes with deep understanding of security threats will find many holes in your system and you'll be grateful. You need to learn about security tools like fuzzers and ensure they are run before release and all issue found are fixed. You need to learn about the penetration testing mindset and either train someone or hire someone to penetration tests your systems. And once you're done with that, you'll need to keep aware of new kinds of security attacks and ensure you are mitigating the attacks before reach release.

So theres lots to learn and do, but there are plenty of organizations embracing a secure by default mindset.

Id highly recommend surveying the literature for a decent book on security process and practices. Writing Secure Code Second Edition by Michael Howard is a great starting place for a newbie or a good review if you're an old timer - http://www.amazon.com/Writing-Secure-Second-Michael-Howard/dp/0735617228/

HTH.

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

[Anonymous Coward]

But a carefully chosen OS with sensible configuration shall prove hard to pirate ain't it? A webserver running in a user-account, installed without being root, with a stateful doing the transparent redirection to/from non-priviledged port, a shell for that user set to /bin/false, a sandbox, non-loadable kernel modules, etc. can bring you a system that is immune to patching for *years*. I've set such systems and haven't seen a single exploit such servers would fall for.

Sure there may be *unknown* exploits but these no patches exist yet for anyway...

Now of course if you plan to run that on a server that needs to be patched every single tuesday : )

Learn the Attacker's Mindset

[stixn]

Read the Web application Hacker's Handbook. Once you can think like a malicious user you will build more secure code. Once your app is almost production ready, have it Penetration tested by a reputable security vendor like Emagined, and then remediate any identified vulnerabilities. Rinse and repeat. Never release a security critical application without due diligence.

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

[Alex Belits]

I would agree with the first part, however "knowing hackers methods" should not matter. Secure software is supposed to work equally reliable when subjected to known and unknown intrusion methods. Any knowledge of specific attacks and its types should have only illustrative purpose.

Servers in triplicate

[Anonymous Coward]

Okay, let's see: 1) PROM your code. 2) run your servers in triple triplicate, two on the incoming data and one completely offline. Let a microcontroller check the settings of the two against the one. Let the three sets duplicate each other, to lookfor errors and flakey behavior. Upgrades are performed on one set at a time, first to view errors and broken upgrades and then to live-test the system. For bonus points, have two completely different programs on different OS systems and different microprocessors(nothing in common but the input and output), to independendently process the data. Then compare the results to each other continuously . Isolate the system from human engineering. Don't believe that anything on Slashdot comes close to addressing what really matters.

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:Start with the W3 guide to secure CGI programmi

[mSparks43]

Java

[almost] end of story.....

SANS perhaps?

[afabbro]

I've heard things about SANS, though I've never taken a course from them. They do have some courses on web development. Even if you can't afford to take one of their courses, you might look through the content brief to see what it covers and what areas you should be looking at, or find someone who's taken the course and ask what was covered.

Re:Start with the W3 guide to secure CGI programmi

[Alex Belits]

Really? C is a safer web language than Perl? Buffer overflows and all?

Yes. To have an exploitable buffer overflow, a programmer has to make a major mistake in the most fundamental area of programming. Interpreters come with vulnerabilities built-in, and often are written by opinionated douchebags, who care more about implementing their pet idea of "how software ought to be developed" than about quality of implementation.

Re:Start with the W3 guide to secure CGI programmi

[Anonymous Coward]

The CGI and Perl specific stuff (per the link) might not be as relevant today, but the gist of it can apply to more modern web programming approaches.

Harden IIS 7

[Anonymous Coward]

If you are using windows os / iis 7.5 is your best option, check out these couple posts. SQL Injection is the #1 thing you should deal with from a programming aspect, don't trust any data inputted, validate, validate, validate.

http://forums.iis.net/t/1127617.aspx

http://www.iislogs.com/steveschofield/how-to-use-security-configuration-wizard-in-windows-server-2008

Very Simple

[Anonymous Coward]

Just read, study and understand W. Richard Stevens books titled "UNIX NETWORK PROGRAMMING - Networking APIs: Sockets and XTI " and "UNIX NETWORK PROGRAMMING - Interprocess Communications". That should get you well grounded for a start. Then study open systems communications, and combine that with you 'development experience'. You didn't say if it was system level or application level. If its all application level, you should study an operating systems text to get familiar with OS design, that will help with understanding stack overflows, stack frames, application I/O execute restrictions (Such as ascii armor in Linux). After reading/understanding that, you should join a systems security group such as http://www.honeynet.org/ and study Fyodors books from http://insecure.org/. At that point, you should be able to build a very secure site, for banking, national security, etc.

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.

A few guidelines

[Animats]

A few guidelines.

• You need three computers - the customer-facing machine, which handles web services, the business logic machine, which runs your application, and the database machine, which runs the database. Communication between them is by message passing and is very limited.
• Strip down all the machines involved in the secure application. None of them should handle mail, or FTP, or web serving generally. You should know why every process on those machines is running, and why every port that's open for connections is open. Only the customer-facing machine is accessible from the outside world.
• Don't use Apache or PHP. You'll need to find a high-security web framework. Even then, all it does is talk to the business logic machine.
• Consider running SELinux. It's a pain to set up, but it works reasonably well.

Re:Start with the W3 guide to secure CGI programmi

[Chuck Chunder]

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

And that never happens, especially to people who implement their own stack rather than using one written by experienced coders in front of a lot of eyeballs!

Obviously there are questions of scale here. If you have the resources (eg you are Google) then there can certainly be advantages (in many areas as well as security) to having your own stack. However if you are just a guy with an idea then you might have to make a pragmatic decision now and worry about some of the issues that come from that external dependancy later otherwise you'll get too bogged down to get a product out of the door.

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.

Secure website 101

[ryanw]

Security for a web app is about understanding that people will be breaking your system and hacking your system, so the goal is to reduce what will be able to be hacked, control the fallout at each stage, control the separation of duties between the web developers, database admins, and says admins with root, and alerting when anything happens on a system.

Security is only as good as your ability to make it work without any one person trusting the other. The system has to be built on lack of trust of any one person in the system. You have to assume that some new-hire is going to a potential problem.

Social engineering or internal crime rings are way worse of a problem for "secure sites" then a hole in some java code.

But with that said, the way you make a secure site starts with a multi-tiered approach having web front ends, an application tier, and a backend database.

Separation of the web front ends, which you assume will be hacked. You remove any and all potential vulnerabilities, services, processes running unnecessarily, compilers, and anything else not necessary to run your web application. Put in place a high alerting system triggered whenever anything changes on a system and potentially rebuilds the servers upon reboot at the most extreme end of things. Have the network rules setup to only allow the single application port from the web servers to the application servers. Don't allow any other traffic.

Next the application layer has a similar lock down removing anything and everything not required to run your app. Only allow the network traffic for the specific ports for the database from the application server.

On the database server maintain adoquite backups and lockdown proceedures for all data.

With all that said, your application needs to go through a security review with several people making sure you're not doing stupid stuff such as: making system calls leveraging variables supplied by end users, make sure to verify every one of the users inputs scrubbing any potential SQL injection, and make sure to double and triple check any time input is leveraged by the user along with a system call, database call, and of opening files or pipes or anything of the sort. The use input is where the hacking takes place.

Anyway, that's how it's done by the big boys. Good luck.

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.

Payment Card Industry Data Security Standard

[peawormsworth]

The credit card industry has a document defining the requirements for creating a server that accepts and holds private customer data. http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard. It is a freely available document that will specifically guide you through every point to cover making sure your setup is secure. It involves everything from physical security of the hardware from theft, to managing user access and passwords, to running security monitoring software, to following best practices for preventing hacking over the web using html holes. You should look into OWASP for preventing scripting, SQL injection, XSS and such attacks. This is primarily for web based security through holes in ur design. You should learn and use the modsecurity apache module. I think u will find that following all of this is a task beyond one person. But if you attempt to do as much as you can from these sources... ur setup will be far more secure then most others and a less likely target. If you really need ultimate security, then u should hire someone to perform some of the tasks that you cannot. Following all of this will be a pain in the butt. And every time u make changes to ur application, u will probably have to rewrite much of the security rules. I dont know what banks use, but this is exactly wat online credit card companies are required to do. Oh yeah... also having a "staging server" which is a duplicate of the live server to adjust and test before sending any changes to the live server is a good idea too. Good luck, but I will tell you that it is easier to hire someone to do this for u. and also get insurance if you have liabilities.

There is no security....

[Anonymous Coward]

...everything written here is an illusion of security and might keep out the script kiddies, but not anyone serious. Sure you can lock down your ports, keep your system patched, use a firewall / ips with only specific ports open, use ssl and encrypt all of your data, but that doesn't account for a lot of things. 1. There will be flaws in the software of your firewall, switch, routers, operating systems, database, libraries and apis. 2. Any system that is connected can be hacked. 3. A person with good social engineering skills can compromise your system in a variety of ways. 4. Your system administrator, dba or developers could steal any data they want as most data theft comes from internal threats. If you think your data is secure, you're wrong. It is just that no one serious is interested in it.

KISS

[Anonymous Coward]

I’d say if you make a reasonable object model, the security should be in your functions validating the user input according to data already present in the system.

Registering bills for remittance could in theory be done without security at all.

You should make a separate identity check/validation for each confirmation of transfer.

And probably people don’t want their balance published, so keep that secure too.

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:Web-specific suggestion(s)

[thsths]

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

I agree, but how exactly is that news? I think in 1993 or so the HTTP standard defined that GET should only be used of operations that are essentially without side effects on the web server (ignoring statistics etc that are flawed anyway).

Of course you could go one step further and also send the session identifier via POST, but I am not sure that necessary nor convenient. Usually the combination of a GET parameter and a cookie should be reasonable secure.

Re:Web-specific suggestion(s)

[IBitOBear]

I never said it was news. I just notice that nobody(*) does it.

(*) obviously some people do follow the rule, but if you pay attention to the URL bar well, the thing hemorrhages information. Combine that with the logging and session ID and whatnot and the use of the query-part of the URL becomes a liability to privacy and safety.

ASIDE: mid 200x, I designed the web-performance measurement section of a device that was sold to cell phone providers in order for them to monitor the throughput of their data networks. I may have been scared by that experience. But having been under the hood of countless web pages (the tool had to fetch pages from yahoo and espn and whatever what hot that month) the use of GET where POST should have been used is endemic, particularly by large providers. Most web designers never read the HTTP standard and when they see that the FORM tag can use GET or POST in the response, and they _must_ pick one, they default to GET for whatever reason. I suspect that the reason is that it is one character shorter, which in today's measured internet service world, can really add up.

Re:Web-specific suggestion(s)

[SharkLaser]

Session ID needs to be in the URL because otherwise every page request would be POST, and that will break lots of functionality. Usually session id goes to cookie, and regardless, they're almost always bound to IP and other information. You can't just copy that session id and log in. It has no effect on security in standard environments (and if you do custom stuff like reverse proxying you need to handle many things anyway), and sessions provide good functionality.

The default is GET because it's better in most cases, like in your example with Google query. This lets people link to pages, bookmark them, let search engines index them and lets user go back and forward in history. POST breaks all that and should only be used when there's actual need for them, like when filling actual forms. In most cases they're used perfectly good.

Re:Web-specific suggestion(s)

[marcosdumay]

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

Isn't it better to learn the actual environment? GET is the verb for retrivering information, POST is the verb for sending information.

Use them acordingly.

Re:Web-specific suggestion(s)

[marcosdumay]

Session ID doesn't need to be in the URL. As you said, it can go to cookie, so as to not polute the URL.

It is better to keep in the URL just the information you need for selecting what you'll display, so it stays a resource locator. Session information is not one of those. Putting session ID on links or bookmarks disrupt some things (caching for example).

Re:Web-specific suggestion(s)

[rcrodgers]

These days, in my opinion, sessions are done better and more securely with cookies; a cookie, for example, can be set to require a secure transmission vector (usually SSL in an HTTPS request), and aren't bookmarked as part of a URL. Yes it is more difficult to see what cookies are stored in your browser than in a URL, but most browsers will allow you to view and/or clear cookies easily enough. In addition, cookies can be set to expire automatically a set time on the client so they're only valid for a specified period of time, which can be completely separate from the server side. For instance, you could create a session that would live for 5 hours, and regularly change the session ID (say every fifth request if you like); the session cookie would get updated each time, but the overall session would live only for that 5 hour window. While the same could be done with a session ID in a URL, that session ID could still end up in a bookmark; in the very unlikely event of the session ID being reused, that bookmark could represent an inadvertent attack vector.

In addition, cookies are passed with both GET and POST requests; not every page has to be a POST request to use cookies to pass session IDs, and as I explained already, a session ID in a URL can be bookmarked. GET and POST have two different purposes, and I think everyone designing web pages could stand to read through the HTTP RFC . Logins should be done exclusively with POST in my opinion, and normal data retrieval once logged in should be done with GET. There's no reason that any search engine should ever be given a session, let alone a session ID; if a search engine needs access to otherwise secured information, there are options to accomplish that, but I can't see the logic in locking up data then making it publicly available in a search engine.

Apply the SDL approach

[natetron]

Actually implementing the security dev lifecycle is a good starter. At minimum create some threat models and identifiy the attack vectors and targets.

Pull out

[Anonymous Coward]

Pull out ethernet cord and remove any wireless adapters.

don't use a framework

[gl4ss]

rule 1. don't use a framework.
rule 2. don't trust inputs. ...
rule 42. don't use phpmyadmin or any such shit. at least not on the production server. have the production server only run the product. kill even sshd if you can get away with it. maybe rig a different machine to it via serial for control.

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.

Can't be done

[Anonymous Coward]

The simple answer is, you can't make a secure web application. It is like making a tamper proof car. You give the user, any user, including hackers, the full source to your application is script form, on a platform that have advanced debuggers build in to the runtime. You can't keep that safe in any way or form.

Now what can be done, is to secure the communication and validate any input from the frontend. So basically, even though you are the developer of the frontend, treat it like you are not, that you are getting data from an unknown source, and treat it like such.

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)

Not good enough

[LostMyBeaver]

Secure coding is not that secure. It takes more than just code to guarantee security. Secure coding checklists are generally made reactively. When we learn about a new way to hack, we add another layer.

For the moment, we're pretty damn sure that a LightHTTPd and Linux or OpenBSD box is going to be rock solid regarding security. Though, there are still regularly security fixes coming out. Sure, it's not as often as earlier, but it still happens.

The code is only part of the problem.

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

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

[Anonymous Coward]

That's exactly what I do for my day job. I have a fairly good idea who practices security code reviews and who doesn't.

The bigger retort is (why am I retorting my own advice??) explain that to google, where they already had good practices and fell down to social engineering.

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

Re:You used banking as an example... good start

[Anonymous Coward]

Great list - I'd add in some "rate limiting" protection - anything on the Internet will get hit by DoS attacks (most of which will fail if you have more than a 2-bit server), but fending off all that traffic costs money, and possibly reputation. It's easier to block stuff you don't like the look of until it subsides. Anecdotally, rate limiting people can reduce your spam overhead (if you have one), and possibly will block script kiddie scans too. It's not going to prevent getting 'hacked', but it can keep the lights on almost as effectively as hack-protection.

I'd throw in multi-level client validation too. One layer is in your code, but another is in a filter application, which has to be (tediously) configured to allow a particular variable to hit the server, provided it's of a form you expect (think: regex checking of input values). The idea here is that you've had to double-think through your problem. If something doesn't work because the filter blocks it, then go check your code and see if it's correct. Again, this isn't going to save you from yourself, but it's likely to stop you being an idiot (so long as you pay a bit of attention to it).

Re:You used banking as an example... good start

[Anonymous Coward]

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.

Your 3 and 4 are total bullcrap.
3) what is it? Turtles all the way down? Eventually something was compiled. I think you mean no "by-hand" cgi. Well duh. Wrapping your server in vm's isn't going to help as much as you think.
4) How in the fuck are you supposed to manage such a system? SSH can be open - with ip tables you can set it to only allow from a specific IP in your DMZ, and then your lb/proxy/firewall networking prevents an incoming port 22 connection to the machine.

Re:You used banking as an example... good start

[LordActon]

COBOL is a crippled language. [...] COBOL is an insanely retarded language. COBOL is generally only used for processing things. [...] 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.

Why is this noise modded up? The only true parts of that statement are equally true for C, depending on what "crippled" and "retarded" mean. The rest is best ignored. For example, I'm sure I've heard of C being used for processing things.

DB/2 sprang from System R, IBM's prototype RDBMS. It competed (indeed, competes) with the mother of all "large scale ISAM" systems, IMS. Last I checked, it represented about 20% of the SQL DBMS market in annual sales.

It's too bad more web programmers (and framework designers) don't know more about database security. I have yet to read about a SQL injection exploit that couldn't have been prevented through fairly basic security measures within the DBMS.

Re:You used banking as an example... good start

[LWATCDR]

You have no idea what you are talking about.
IBM pretty much invented SQL. DB/2 is and SQL database and competes with Oracle in the market.
http://en.wikipedia.org/wiki/IBM_DB2

Re:You used banking as an example... good start

[LostMyBeaver]

Ok... I'm sorry I hurt your languages feelings...

DB/2 is precisely what I said... it's a large scale ISAM ... and all ISAMs are relational databases if used as such. DB/2 is the back end of a system which surprisingly enough also has an SQL front end. However, secure code does not use the SQL front end as such. They perform searches against explicit indices. COBOL doesn't need SQL to find to a data set with DB/2 and for the most part is slower in most cases if you do. If you're performing a search using an SQL query as opposed to an index then you probably don't have the index and therefore it's inefficient. So I just don't see what you're complaining about. Or were you just using the opportunity to show that you knew about System R.

And... to be a weener... just because DB/2 supports SQL and when compared to other SQL DBMSs it accounts for 20% of the market, it doesn't mean it was purchased or is necessarily used as an SQL server. DB/2 from an SQL side is pretty boring and I won't say whether it's a real competitive product or not, but it's not like when you're looking for an SQL server you immediately think DB/2, instead if you're using DB/2 and you want to connect to it from something other than your COBOL or other ISAM based code, you use SQL.

Your last statement isn't so bad... but you need to consider the real issue which isn't SQL injection, it's SQL connection. Although SQL does have security levels and such, if you hack into the web server and want to read the contents of the database on another server, the ability to write generic queries in SQL makes security a much bigger job and much harder to pin down. Though, I'm not against the idea of using stored procedures for all queries and disabling remote use of select. So long as the stored procedures are required to check the format of their parameters before using them. SQL is too generic for a secure system... it's great for pumping out lots of code really fast... and on the database server, there's no reason to not use SQL accessing data. But there should be no possibility for the web server to execute SQL scripts directly on database server. In fact, this is a great place for DB/2 as it still has highly evolved ISAM RDBMS APIs without having to depend on SQL.

I'm sure we could have a religious argument about this. But, I'm amazed that on one hand you're defending a COBOL as not being crippled (which I stand by... yeh you can do absolutely anything, just need the APIs and those need to come from another language or you need to hack them to hell and back). And COBOL generally being used for only processing things is precisely why it's so good. C on the other hand is generally used for doing absolutely everything and there's an API for it. And that's why for security it is so weak. You can do everything and generally people DO do everything. Sure it can be used for "just processing", but the amount of code needed to write secure C code is substantially greater and harder to manage than it would be in a simple garbage collected, bounds checked, exceptions based environment.

The biggest problem in security is that web programmers are just web programmers, system administrators are just system administrators and to do anything useful, it would be far beyond the reach of a single person to cover everything. So, if you design the system from the start with the idea that "Someone will miss something" and "Not everyone will understand it all" and "Sooner or later there will be a new guy and he'll start changing shit before he knows all the policies", then you design a highly secure system based trying to limit what can be done without extra work.

Re:You used banking as an example... good start

[LostMyBeaver]

Uhh... yeh... and how does that contradict what I said? DB/2 IS an ISAM and there IS (though I didn't think it needed mentioning as it's irrelevant) an SQL front end to it. But, if you designed your database properly and are using COBOL, I can't imagine why you would want to use SQL. Then it just seems almost redundant.

Re:You used banking as an example... good start

[LordActon]

You didn't hurt my feelings. I haven't written a line of COBOL since the summer of 1988. Rather, I was objecting to arrant nonsense masquerading as authoritative-sounding statements. That kind of thing can harm the reputation of Slashdot, you know.

all ISAMs are relational databases

Any defense you attempt of that proposition will only land you deeper in the tall grass. ISAM can't be "used as" a relational database because it lacks the fundamental facilities.

The most widely accepted informed definition of the relational model is the three-part test Codd described in 1978: structure, operations, and constraints. ISAM includes no algebra and very little in the way of constraint enforcement. It also fails most of Codd's 12 rules.

I think you might mean that ISAM files have keys, and that ISAM files can be arranged in ways that mimic normal forms. The comparison is superficially appealing and logically vacant. Sorry.

However, secure code does not use the SQL front end as such.

Do please tell. I'd especially like to know what "as such" means in that sentence. Googling "isam db2 site:ibm.com" fails to turn up anything relevant. Searching DB2 Documentation for "isam"s turned up nothing.

I'm not against the idea of using stored procedures.... So long as the stored procedures are required to check the format of their parameters

No, that's unnecessary for purposes of security. Again, one of the three legs of the relational model is constraints. The DBMS is perfectly capable — more capable than the stored procedure, more than the application — of preventing inconsistent data from entering the database. It can't ensure correctness; no mere machine can. But only the DBMS can enforce referential integrity and declared constraints versus other contemporaneous processes.

But you're right that if the webserver can only execute stored procedures and has no other rights in the DBMS, then the data are absolutely safe from arbitrary manipulation through SQL injection. (Yes, I understand the procedure could be written to execute its parameters as code. But anyone letting data in any form be executed in a web environment might as well start looking for other work now. Why wait until the fan gets dirty?)

By contrast, no file system offers any such protection. If the webserver can access any part of the file, it can access the whole file. Own the server and you own the data.

SQL is too generic for a secure system

I don't know what that means. I can't even venture a guess. I guess Lisp is too generic too for a secure system. That explains why Paul Graham is sleeping under bridges instead of funding startups.

I'm amazed ... you're defending a COBOL as not being crippled ... you can do absolutely anything, just need the APIs

I'm not defending COBOL. I can think of a dozen problems with it. I'm ridiculing the crippled/generic taxonomy you proposed. C has no I/O capability and no memory management save static storage and the stack. What can anyone do with such a toy? Exactly the same is true for Java. COBOL on the other hand, like Pascal, at least defines I/O in the language. Even with the stdio library, can you do in C what COBOL does in 64 lines?

Your basic assertion seems to be that a simple system is less vulnerable than a complicated one. While that's partly true, I have to remind you of Einstein's dictum to make things as simple as possible but no simpler. When you recommend eschewing tcp/ip as "too complex", I see an invitation to reinvent it badly. It's not easy to improve on the socket mode

Re:You used banking as an example... good start

[Anonymous Coward]

You suggest to avoid IP by using dedicated network protocols such as Ethernet, Infiniband or serial port. On the other hand I think it is best practice for high security to encrypt all links between machines even within the same data center. Does this implicate to develop our own proprietary encryption protocol to protect this link? You know that this would not be best practice either because it probably wouldn't resist against sophisticated cryptographic attacks unless it is a proven protocol which has been reviewed extensively. Hence, are there any appropriate existing encryption protocols without the drawback of getting a complex (and potentially hackable) IP stack in?

Re:Start with the W3 guide to secure CGI programmi

[dotancohen]

Never mind that this example assumes that you're engaging in the egregious sin of editing a file on a production system.

All too common. My current gig is developing for a vBulletin application with VBSEO, both are proprietary products with their own license scheme. Basically, in order to configure a test server that exactly mimics the production server and allows each dev to have his own test environment, we would have to shell out for a new license for each dev. Er, no- we went back to editing on the production server.

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

[Anonymous Coward]

I will happily debate you on checklists. First off, checklists are working for aviation safety and, soon hopefully, for medicine safety.

You will note this doesn't mean Grandma could have safely ditched Sully's plane into the Hudson, armed with a really good checklist. But in software security, there are a handful of simple sub-skills to learn, like data input validation or output validation, as a number of people here have pointed out.

The checklist mentality allows a more skilled security analyst to come in and review the trust boundary definition, the login and session API, and for architectural flaws. Without weeding through thousands of XSS and implementation flaws first.

It also paves the way to standardize critical communication like handover of the app to production service ("what, they've been using the debug configuration file live?? How did that even happen?")

The only sensible alternative to checklists would be to hire nothing but seasoned security consultants for your technical staff. In which case, they would write checklists for themselves anyway...

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

[Anonymous Coward]

LOL dude. You spent 10 minutes writing a paragraph how you are secure only to deny yourself that in your next paragraph:

Sure there may be *unknown* exploits

That's right. All I need is an unpatched security hole in your web server software or the webapp language framework you're using or the database software you're using. All I need to do is wait.

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

[Anonymous Coward]

The greatest checklist of them all is OWASP Top Ten (2010).

Start with that and your site will already be well above average.

Then, blow your money on a few days with a good security consultant (GDS, Cigital, HP Webinspect et al.) and have them help iron out any additional architectural flaws.

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

[sprint907]

unplug the box

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

[xenobyte]

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.

Exactly. The worst mistake is to think that you are 'safe' because you're inconspicuous or uninteresting. Automated tools don't care and besides, at lot of base hacking is all about acquiring 'real estate' in the form of 'owned' servers. Such servers are always left almost untouched except for a back door, in case the server is patched later. These servers are used to hide the true source of intrusions and to stage attacks from, and for these purposes inconspicuous servers are exactly what the hackers are looking for.

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

[FormOfActionBanana]

Could you be more specific? I read a book on social engineering recently (No Tech Hacking, Johnny Long) and my "placeholder conclusion" for the time being is that good social engineering cannot be protected against.

I'm really curious about how this can be done in a systematic way. Thanks.

Re:Complexity, Time and Money Prevents Good Securi

[Terrasque]

A good framework can help a lot in some regards.. For example, I often use the Django python web framework.

SQL injection

Got its own database abstraction layer (ORM), which practically eliminates that problem. Also gives the bonus of easily moving to a different database and automatic creation of test databases, but lacks some flexibility (and of course, makes some stupid SQL here and there). You can also write raw SQL, but in the vast majority of cases that's not needed.

validation of inputs

Has it's own system for generating, processing and validating forms. Greatly helps with that problem. Also makes re-use of input logic much easier :) The framework also have an optional per-page or site-wide layer for protecting against CSRF attacks.

cross site scripting

By default, ALL variables in templates are HTML-escaped. While you still can (and sometimes need to) declare variables as raw, it's something you actively have to enable on a case-by-case basis. Which means that you only have to think about it on the exceptions, and not everywhere.

Re:Meet my friends Greasemonkey, TamperData, and S

[kangsterizer]

"6. Lastly, if you are running standard open-source packages test your site for cross-scripting vulnerabilities. "
so closed-source packages are immune to XSS? Great!

I'm also amazed how many people offer their services through /. in this field.

I'm also not sure where you want to store your sql credentials. they're to be stored somewhere and the backend scripts have to access sql. from that point on, what you write is moot.
instead you probably mean "be careful where you're storing simple things such as passwords, and what can access them".

finally, don't "close down ports you don't use". instead "close everything down and open what you use". on the network point of view that's easy and the general practice.

Mandatory- In safe w/out power

[Anonymous Coward]

How fast can your servers be? How slow can your service be? How remote, shielded, monitored - and yet immediately serviceable can they be? How much hassle and discipline can your IT staff bear without subterfuge, corruption, mutiny, and sabotage? Your contractors? Their contractors? How much can you invest in 'standard' security? Badges, ID checks, drug tests, lie detectors? Psych profilers, etc.? How much can they be trusted, or audited, before you're chasing your own tail? How do you vet visitors, delivery folk, building maintenance? Everywhere?

Will every client bear shackles ... er, dongles of some sort? Can you flash-test your clients security? What will you do to keep them from writing the 4 or 6digit (hope not, nor static) password and account numbers under their keyboards - or their secretary's? Or the intern's?

Can you implement one-time cryptography? Do behavioural analysis of transactions, flagging uncommon transactions on a grade? Immediately?

Good Luck.

Invest in PR and Legal.

Yours unruly : oldandwhatdoyoumeancynical

Big difference: Secure vs. Looking secure

[Anonymous Coward]

Banks just need to 'look secure', that's part of their publicity advertisement bluff.

If you really *want* security, you will have to deal with completely different strategies, involving much more than just software-engineering, but much more social engineering to your users.

a banking account management system

[yacc143]

That was a good one ;)

That's simple, forget about the IT side, get yourself a good legal dept and some lobbying, and push liability onto your customers.

User login

[ianare]

One thing I've seen on my bank's login page which I haven't seen anywhere else is that to enter in your passcode (a randomly generated code given by the bank, used in addition to the user password) there is no way to enter in the code with the keyboard. You have to click on a number pad with the mouse, and the position of the numbers will change on each page refresh. This makes it impossible to use keylogging software to steal your security code.

Re:That wasn't the real reason to avoid using Perl

[Anonymous Coward]

That's simply not true. C's runtime environment is just as complex as Perl's (or Python or Ruby). The only difference is that you write your own runtime environment in C, thus increasing the likelihood that a bug exists that you don't know about. Using a scripting language at least more people are developing the interpreter and trying to fix bugs in it.

more stuff for your checklist

[son_of_asdf]

- avoid blacklisting input where ever possible. Accept known good, reject everything else.

- Encoding is going to be a problem. Be extra careful about how you handle encoding and decoding. An attacker will encode malicious input to get it past filters. Never assume that because you have obfuscated data with, say, base64 encoding, that an attacker won't be smart enough to decode it.

- Assume that an attacker will be able to breach your defenses, so make it difficult for him to do damage once he has compromised the system. if you have a particular function that accesses 'crown jewel' data, spend extra time making that function extra awesome. Minimize the privileges of the SQL accounts you issue queries with. That is easier said than done, of course. Layer your defenses, harass, annoy, and otherwise dispirit the enemy in a hundred small ways and make him move on to a softer target.

- Use frameworks. Don't try to roll your own if someone else has already don't the tough stuff for you. Writing a good login management system is hard to do right. Stand on the shoulders of giants if you can. This makes updates easier to manage too.

- Do all of the other stuff that I didn't mention here :-)

Use type systems

[dotbot]

to help avoid certain vulnerabilities/failures. E.g. see http://www.impredicative.com/ur/ If you're not familiar with functional programming, this will be somewhat mind bending.

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

[monkeyhybrid]

I'd never heard about OWASP before but I found the Top Ten you refer to well worth taking in.

Direct link here for anyone interested: OWASP Top 10 Application Security Risks

Formal design, fail-closed programming, etc.

[octogen]

Design your application and implement your code to let it do exactly what it should do and nothing else.

Put more specificaly, if you want to add two numbers, make sure that there is no way the result could be out of the range of its data type. If you want someone to enter a name for something, define what that string can contain - maybe only a to z, A to Z, 0 to 9, and it must have a length from 1 to 20 bytes.

Write every function of your program so that it has deterministic behavior, and that it has a clearly defined result for every possible input.

By the way, I doubt that banking account management systems are as secure as people might feel comfortable to think they are. Most commercial systems have poor security, because companies prefer cheap but insecure mainstream IT systems over expensive but secure custom IT systems.

What's wrong with this picture?

[Anonymous Coward]

http://uptime.netcraft.com/up/graph?site=www.dowjones.com

* As the old adage/saying goes - "Will wonders NEVER cease..."

APK

P.S.=> Pretty much "blew me away" when I saw it ( & the result even made me question what Dow Jones is reporting back + even NetCraft's findings there - oddest mix I ever saw actually, assuming it's correct & I'd never thought I'd see it!), e.g.:

OS Server Last changed IP address Netblock Owner
Linux Microsoft-IIS/6.0 10-Dec-2011 88.221.94.201 Akamai
Linux Microsoft-IIS/6.0 10-Nov-2011 88.221.94.201 Akamai
Linux Microsoft-IIS/6.0 10-Oct-2011 88.221.94.201 Akamai
Linux Microsoft-IIS/6.0 10-Sep-2011 88.221.94.242 Akamai
Linux Microsoft-IIS/6.0 10-Aug-2011 88.221.94.242 Akamai
Linux Microsoft-IIS/6.0 10-Jul-2011 88.221.94.242 Akamai
Linux Microsoft-IIS/6.0 10-Jun-2011 88.221.94.242 Akamai
Linux Microsoft-IIS/6.0 9-May-2011 88.221.94.242 Akamai
Linux Microsoft-IIS/6.0 9-Apr-2011 88.221.94.242 Akamai
Linux Microsoft-IIS/6.0 9-Mar-2011 217.156.169.176 Global Crossing

... apk

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.

Don't roll your own crypto

[fa2k]

Use peer-reviewed, open crypto algorithms where possible. (including hashing, key exchange, bulk data encryption)

easy

[roman_mir]

here is what you do:

write all of the software you need on paper first, then

redirect all inputs and outputs into /dev/null

disconnect the Internet cables and pull the electrical cords out of the walls.

done

I once had a software project...

[Tanuki64]

...in a bank. My answer to this:

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

..is: Buahahahahahahahahahahahahaaaaaaaaa......

WAF

[Anonymous Coward]

Hi, ever heard WAF or "Web Application Firewall"? Too put it simple, it's an IPS for web application, it placed between your server and your client so it can inspect and filter the packet. It can go deeper (up to layer 7 in OSI Layer), some brand use both positive(whitelist like firewall) & negative(pattern defination like IPS or AV) security model. It's not exactly the firewall like the name suggested, it's more.. It cannot guaranty 100% safe, but if your site got hacked, you can blame the vendor..

network AND application penetration tests

[Anonymous Coward]

If the highest level of security is essential you should hire a third party to conduct network AND application penetration tests when your development is complete (or almost complete) and periodically thereafter. I work for a large financial institution and we require this of vendors who handle client data and $$.

w3af

[Kamoo]

Also check out the Web Application Attack and Audit Framework at https://community.rapid7.com/community/w3af

Get Certified

[Anonymous Coward]

If you can get certified as CISSP, CEH, GSEC, or OWASP you'll have an understanding of what it will take. Layered security, defense in depth. If you're serious about making your app secure, you should be able to pass at least one of these tests.

Re:That wasn't the real reason to avoid using Perl

[Anonymous Coward]

Well considering there are vulnerabilities in libc/glibc occasionally, I'd say C (or rather the standard lib implementation) can have holes. That ignores that it's harder to write secure code in C for web programming because you have to do everything yourself. It's very tedious to do security tests on input in C.

99% of all web security issues are based on bad input checking. Cross site scripting, sql inject, etc are all because someone didn't do proper input checking. The dirty little secret is that it's HARD TO DO IT. A security researcher will tell you otherwise, but all their sample apps take integers or a subset of basic ascii as input. Anyone who's written a real webapp knows that people copy and paste shit from word and want formatting or other craziness. Consider a blog, job site (resume upload), etc. The input validation for these types of things is crazy and damn near impossible if they accept unicode characters.

Don't expose the server to the web at all.

[ThreeGigs]

If you really want to go above and beyond, don't let anyone access the web server directly at all. Instead, they would connect to an OS session on a machine you control via VNC, or perhaps Citrix Metaframe, etc.

The 'desktop' they're accessing can only access your 'web' server. Your server can't be accessed from, nor can it access the internet at large. The 'desktop' they access can be as locked down as you want, probably only showing a single app or browser running in a 'kiosk mode'.

In one swell foop (grin), you'll have eliminated almost all attack vectors, and as long as you have good input sanitizing between your 'kiosk app' and database, you should be fairly safe, even from future 0-day attacks.

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

[gorzek]

A big part of it is controlling information--and access to it--inside your organization. Anyone who cold calls your office should not be able to reach someone who is both a) capable of handing out sensitive information and b) not informed enough to realize the information they're giving out is sensitive.

A really trivial example would be something like a receptionist knowing the access code to the server room. Some guy shows up with a toolkit, claims to be from Dell, says there's a down server and it's absolutely critical he gets into the server room immediately--the first person he encounters should not be someone who can actually give him that access, as they most likely do not understand the implications of granting it.

Instead, you have a small number of people with such sensitive access--a primary and two backups--and anyone who wants in has to go through those individuals, and they should be technically-oriented and fully cognizant of the consequences of granting someone access to their machines.

Likewise, any data on your company's public network should be segregated so that everyone doesn't have access to everything. Developers don't need access to HR data. HR doesn't need access to development systems. Marketing doesn't need access to development systems. With a decent privilege system in place, social engineering attacks are much less effective. Such attacks often work best when you get someone who, again, has access to interesting information but doesn't realize its importance to the attacker--so they don't realize exactly why they shouldn't give it out. By "access," I mean both physical and network access. Developers where I work cannot physically get into the server room, only IT can. We do, however, have network access to particular systems in the server room. This is as it should be.

Another important aspect of preventing social engineering attacks is having a security culture across your company. This does not work overnight. You have to really drill into your people why you control access the way you do, and why you never, ever give out information that's not really yours to share just because someone sounds desperate. Have a procedure for handling those types of requests and follow it to the letter. For emergencies, have a defined process for expediting any requests--but still make sure they get to the right person. You can't afford to cut corners on this. Everyone needs to know your security policy, why you have it, how to follow it, and clear consequences for ignoring or subverting it. If that means firing people, so be it.

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

[gorzek]

Er, the person designing the software absolutely should know in what ways someone might attack it, otherwise how are they going to secure it?

A developer should know, broadly, what attack vectors their code might be vulnerable to--injection, overflows, etc.--and code to avoid them. But that's all part of having a security-conscious development organization. You are right in that they shouldn't be guarding against very narrow, specific attacks, but knowing what the general methods of attack are is absolutely essential, otherwise what is it you're going to defend against?

I think what people (particularly those who are not developers or system administrators) often fail to realize is that security isn't something you can easily bolt-on later, it should be built into the application/system from the start. Unfortunately, just about all organizations are going to wind up buying software to which they have no access to source code and no guarantees that there's any reasonable security built into it, so you still have to protect it any other way you can.

OWASP....

[Anonymous Coward]

Start here: www.owasp.org

Regards,

Rene Pilon

Making web sites secure

[Anonymous Coward]

1) Use a static code analysis tool for security like Fortify360.
2) Hire white/black box testers (eg. Sandia Labs) to identify remaining weaknesses

The OWASP guidelines

[jcaren]

are a good start.

Re:Start with the W3 guide to secure CGI programmi

[Alex Belits]

Solution: fire all frauds, leave professional programmers. Yes, it's possible to write software without buffer overflow and other glaring errors. If it wasn't, highways would by now be covered by two layers of cars disintegrated while driving.

Re:Start with the W3 guide to secure CGI programmi

[Alex Belits]

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.

C is nothing like assembly in that manner. Indeed it requires a programmer to think, how his data fits in memory. However any sane programmer creates an interface for that, and writes his data only through a safe interface he wrote once for any particular data type or store in his project. Considering that the number of "kinds of things" being stored is nearly constant for most of the project's lifetime, this only increases the amount of time and effort spent at the very beginning. This, contrary to the widespread myth, makes C great for large, long-running projects (ex: Linux kernel).

Assembly, on the other hand, provides no way to properly enforce types in interfaces created by a user, and contains no unified interface to memory allocation, thus preventing such approach from being applicable.

Different levels to be considered

[Anonymous Coward]

As you already recognize, there is more than just writing the secure software: It's also securing your infrastructure and underlying platforms.

For your software, as you can imagine, avoid writing everything from scratch. Just like you should never write your own encryption algorithms anymore, you shouldn't write your own web framework. :-)

I'd recommend using a web framework, which has a good track record in security. For example, I'm using Django (Python web framework) and it does a good job taking care of the usual suspects: Cross site request forgery protection, automatic input and output sanitation, etc. I'm sure Rails and others will do this as well. The idea is that there are a lot of little details to take care of and you are bound to forget something along the way. If some new threat comes around, they usually provide upgrades to handle those as well. Build on the effort that others have put in and start with one of those frameworks.

Secondly, rather than trying to be a super sysadmin, consider using a PaaS provider. Either Google App Engine, or just Heroku (or similar), where the servers themselves are maintained by someone who generally knows what they are doing.

If you really want to go the route with your own server, take a well supported base OS (Debian, Ubuntu, etc.) and follow the many tutorials they have on the Internet about securing those. It usually involves switching off all unnecessary services, keeping security updates enables, etc.

Finally, consider this: I don't know what your app will do, but if you plan on storing credit card information... don't. If at all possible. There are payment gateways and services that allow you to let them store those for you. If you do it yourself, there are regulatory requirements (PCI-DSS), which are utterly silly and very annoying and can make it close to impossible to provide this yourself (need to be able to physically lock away your servers, etc.).

Re:Start with the W3 guide to secure CGI programmi

[0ld_d0g]

However any sane programmer creates an interface for that, and writes his data only through a safe interface he wrote once for any particular data type or store in his project.

That is OK but in the real world a team will contain programmers of various skills. If they ever have to deal with your code you have to explain your interface to your co-workers. Even then they might use it in a way that you didn't think of. If you change it you have to re-explain it. If you change jobs the next person might not understand your interface, etc. Dozens of opportunities for misuse and introducing bugs. We already know how to deal with this. The human mind is much better thinking at the algorithms level than thinking at the machine level and remembering which piece of code allocates/deallocates memory, remembering lifetimes of resources and which API permits transfer of ownership of allocated memory, which APIs make copies of memory, etc.

I have not claimed that there are no benefits to C. That would be untrue. There are specific areas I have mentioned where it is the correct language to use. Also, BTW Assembly has also advanced - High Level Assembly allows you to write code at a fairly high abstraction level - They have classes, structs, exceptions, etc. Ofcource in my experience the majority of programmers cannot produce assembly that will consistently beat an optimising compiler, but that's another topic.

Time and priorities

[GWBasic]

In order to have a secure web site, you need time and priorities. All of a sudden, you'll find a security hole, and you'll have to drop everything to fix it now. If you're busy constantly adding new features, you will inevitably create more holes and not have time to fix the old ones.

Re:Start with the W3 guide to secure CGI programmi

[Alex Belits]

That is OK but in the real world a team will contain programmers of various skills. If they ever have to deal with your code you have to explain your interface to your co-workers. Even then they might use it in a way that you didn't think of. If you change it you have to re-explain it. If you change jobs the next person might not understand your interface, etc.

In other words, design and document your code, and make sure you won't have to redesign and re-document it every week.

Oh, wait, you can't write half-decent code in any language without following the same rule! What a coincidence!

Re:Start with the W3 guide to secure CGI programmi

[Anonymous Coward]

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

At the bottom of the referenced page is this:

$Id: wwwsf4.html,v 1.11 2003/02/23 22:46:27 lstein Exp $

Not exactly up-to-date, is it?

100%

[bWareiWare.co.uk]

Saying you need something 100% secure or 100% reliable simply tells people you haven't even worked out how you are going to measure security or reliability.
First decide how you are going to measure security, then work out the trade off between development time and cost per failure, then you can start talking about what % would make a sensible goal, then you can start asking how to achieve that goal.

Lots of factors...

[Anonymous Coward]

I would not use something like C where stack overflows are even possible. In a general sense, whatever language you do use be aware of what kind of potential vulnerabilities it has so you can look for them, and if possible pick a language that has fewer of them.

          Validate all input (i.e. filter out characters you won't be using on all inputs to make sure SQL injections, HTML injections, dropping to a shell, and so on are not possible.) Make no assumptions that the client will treat output properly (well, it has to behave for usability, but you can't rely on sending something to the client then requesting it not show it to the user for security, since the user could use wget, or lynx, or choose "view source" in firefox, etc.)

          Don't trust anything. Cookies, expecting because you tell the client to go to some URL that it will, relying on the client to run the javascript you tell it to, and so on. I mean, you might need that stuff to work for your site to *work*, but for security purposes you have to consider what happens if John Q. Hacker passes back a different cookie, a different URL, and so on. I recall reading about at least one site in the past, part of the URL had something like "UID=00001" so someone found they could replace that bit of the URL with "UID=00002" and voila! Some other person's account pulled right up.

          In keeping with the above, if this site keeps any kind of a user state (i.e. a session on a web site.. virtually anything where you log in, do stuff, then log out) then be really careful in considering session expiration policies, and making sure session handling is secure. Do research on what mechanism works for you. Poor session management results in "UID=00002" bringing up someone else's session. Strong session management would user perhaps a cookie, a session ID in the URL, *and* perhaps a requirement the IP address matches the one in use for that session; you'd also perhaps want a short expiry time for the session (so if someone forgets to log out, there session drops in 5 minutes instead of sometime in the indefinite future.)

          Check your permissions. Then check them again. Obviously nothing should run as root, but if you have your web stuff and your sensitive data both owned by "www-user" for instance, then if someone finds a flaw in your site they could read out your sensitive data. It goes without saying, the sensitive data must not be under your web server root (apache or whatever.) I would have the sensitive information owned by a different account, and not readable or writeable by the www-user account at all, so any access to this data must go through your code, and not potentially through whatever some hacker gets to run as www-user.

          Consider what access you do need. For instance, I suspect quite a few credit card handling web apps retrieve the full card number for processing, even if they only display the last 4 digits. If I were handling credit cards, I would have it so the web app would handle cards through a seperate card handling application (not running as www-user) so the web app could *ONLY* 1) Add a credit card to someone's account. 2) Delete a card. 3) Retrieve last 4 digits. 4) To purchase stuff, the price would be sent to the card app; obviously this part would have to be especially carefully designed so erroneous charges could not be made. i would provide NO way for the web app to EVER retrieve the full credit card number (so if someone pwned your www-user account, they would still have no access to CC #s.)

          Lastly, for what you specifically want to do, carefully decide how much "custom" code you want and how much you can use off the shelf. Some web frameworks have taken a cavalier attitude to security, so you must look at reviews and such. But, honestly if you mainly use software that has already been gone over by dozens or hundreds of people for security flaws (then write a bit of "glue code" following the above guidelines) it'll probably be more secure than if you write it all from scratch.

nearly impossible

[Anonymous Coward]

It is nearly impossible to secure a web application using the technologies and development methodologies that are currently in vogue. Even if you put in place the process required to build and *operate* secure software, which is often prohibitively expensive, it is likely that the technologies beneath you on the stack are not as well engineered. To make matters worse, the solutions available to improve the security posture of an application after the fact are generally not worth the trouble. They are good at finding obvious or outdated attacks or problems, but offer no real comprehensive protection. There is just no good answer and a read of the headlines makes that obvious.

The best I can suggest today is to decide what the risk is in terms of dollars if the application were compromised. Decide what portion of the potential exposure should be spent securing the application. Combine the cost to build the application and to secure it and decide if the business value of the application exceeds the costs of building and securing it. If it is still worth building use the additional resources for:
1) better monitoring so you'll know when you've been compromised earlier
2) building a more secure application
3) additional technology and process around infrastructure level security issues

There are much better solutions to the web security problem in the pipeline, but none to my knowledge are available today.

Here is a entertaining writeup of where the industry has gone wrong: http://www.ranum.com/security/computer_security/editorials/dumb/

Note the date.

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

[the_B0fh]

who let the kids in here?

So here's my brain dump

[Beeftopia]

I'm using an internet-facing LAMP server. Here's what I do:

1) Make sure remote root logins are disabled on your box.
2) Use complex usernames and passwords. I look at my log files and realized they need a username and password match. A lot of the ssh attacker usernames are pretty simple. Don't use common usernames. A lot of times they spin their wheels trying to log in as root. You should only be able to su to root once logged in as another user.
3) I use MySQL. Don't allow non-localhost logins. Applicable to any database probably. The user would need a successful login to touch your database outside of the interface.
4) Use iptables, the linux firewall. Close all ports that you don't need. Leave open only port 22 and 443 and 80 (ssh, https, http respectively).
5) Use a brute-force attack limiter like fail2ban. It works through iptables which is a packet inspection program. Fail2ban is a python program. It won't allow the connection to get to the password authentication module once an IP is banned.
6) Every piece of input you get on the server must be sanitized. "Stripslashes", "htmlentities", "strip_tags", "mysql_real_escape_string" protect against SQL injection attacks and cross site scripting attacks.
7) Set up file and directory permissions correctly.
8) Use established, commonly used security programs. Don't try to roll your own. The established ones have been out there and have been looked at.
9) Implement https. With Apache, you need to add 2-3 lines to a config file. Get a book on Apache. There's info on the web. Doing this prevents usernames and passwords from being transmitted in clear text. Very important.
10) Check your log files routinely. auth.log, error.log, other_vhosts_access_log. Great fun. Plus you can see if there's any odd activity.
11) Use unusual names for your directories. Typical port 80 scanners just test for like 100 or so common directory names.
12) Turn off the ability to list directory contents.
13) I use PHP sessions. Additionally, I store data about the user (ip address, username), and check it every time they start to execute a script. If what's in the session cache on the server doesn't match what I've stored on their machines, I give them an error page. They can't execute any of my scripts without valid, non-stale login credentials.
14) Use POST instead of GET. Avoids session hijacking that way.
15) Turn off error reporting in PHP on your production server. Fail without comment, unless it's a foreseen failure path.
16) Only allow cookie-only sessions.
17) Encrypt important stored information like passwords. Salt them. I don't know the passwords on my system. That's because they've been run through MD5 with salts.
18) Enforce minimum password lengths for your web interface. Learn about that with regular expressions.
19) Prevent listing of PHP files.

So that leaves... the ughknown. I see in my logfiles where attackers are constantly trying to test different directories on my website. Like I said above, unusually named directories. A custom naming structure perhaps. Read technical websites for talk of new security breaches. That's a big one. There was one recently where big POST strings could bog down a server. I set the right settings in my php.ini file and now it's no longer an issue. Things like that.

What about things like buffer overruns and... what else? Aye there's the rub. The "what else." Make a point of reading about security as much as you can. Complex items like buffer overruns are pretty much scrubbed from the popular tools. If you roll your own security you could be vulnerable.

So, I talked about a LAMP server but the concepts are probably pretty portable to other systems.

So, there's my $0.02.

Not another bitcoin exchange!!

[DamnStupidElf]

Seriously though, if you want to write a correct (or secure, same thing) application, use a type safe language combined with a formal modeling/proof language. There are dozens of choices and you can formally demonstrate any predicate that you care to, up to correctness for your entire application within the constraints of the programming/modeling environment.

Re:Start with the W3 guide to secure CGI programmi

[0ld_d0g]

Sure, but you missed the point. _You_ may be a good programmer and design and document your code but the C language still makes it easy for other people to misuse it. You can blame the programmer, but if a different tool/language can eliminate entire classes of bugs then that's a _good_ thing. This is obvious but I think either you (1) have worked on projects with under five people or (2) have been lucky to only work with experienced C developers.

Discount NBA Basketball Shoes

[buleross]

Discount NBA Basketball Shoes
NBA Basketball Shoes
Basketball Shoes Online
Cheap Nike Basketball Shoes
Nike Basketball Shoes
Kobe Shoes On Sale

Monster Beats Tour By Dr. Dre
Monster Dr Dre Headphones
Monster Beats By Dr. Dre Studio
Studio By Dr Dre
Monster Beats Dr Dre

Re:Start with the W3 guide to secure CGI programmi

[Alex Belits]

Eliminating classes of bugs is a fool's errand -- the number of bugs produced by a programmer is constant per functionality implemented (or time for really bad programmers) and only depends on programmer's quality, so people will just write different, harder to find security bugs.

Re:Complexity, Time and Money Prevents Good Securi

[CodeBuster]

Unless you're working for some hip startup or the project is a secret "skunkworks" type that management cannot interfere with because they don't know about it, you're not likely to get open source frameworks past the bureaucracy for approval. The managers, who've never heard of Django, Joomla, Drupal or any number of other frameworks immediately refuse such requests or intervene to force integration with Microsoft, Oracle or IBM products that theycompany has already paid for with support. Now, before you start complaining that open source is neither obscure nor expensive, I'll just stop you short by saying that it doesn't matter. Management perceives anything not backed by an approved vendor, complete with paid annual support, as being expensive and difficult to support. Those perceptions are reality at many US companies.

Finally, I've yet to see a full-service web dev framework that I really like anyway. I don't want to waste time fighting someone's idea of "helpful" abstractions that are actually poorly thought out, leak all over the place, put me in coding straight-jackets and generally cost me more time than they save. Good framework design is a hard thing to do well and frankly, most people suck at it. IMHO, better to curate your own library of "good" solutions to neat little problems rather than accept some Framework, warts and all, written by some else. The best frameworks provide support and choices, but don't impose themselves where they aren't wanted and get out of the way when you need them too. In my experience, such frameworks are few and far between. Plus, much of the open source code out there is really of average to shit quality anyway, to which the excuse is generally, "don't complain, it's free". No thanks.

Linux Security Admin Guide

[Anonymous Coward]

http://www.linuxsecurity.com/docs/SecurityAdminGuide/SecurityAdminGuide.html

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

[Ihmhi]

(Apologies in advance for the late reply. I haven't been on Slashdot for a day or two.)

Well, I'll be vastly oversimplifying things here, but a challenge/response is helpful.

The military uses such a system to this day, and it was instrumental in WW2. During the Normandy airdrops, American troops would say "Flash!" (challenge and/or sign) if they couldn't visually identify a troop. The proper response was "Thunder!" (response / countersign). Something like this set up would be easy and as secure to use as passwords but would protect against social engineering.

Moreover, "duress" countersigns could be used. Let's use the example of a bank. The sign is "Canary". The countersign is "Bluebird". The *duress* countersign is "Robin". Say that a wealthy man calls in requesting a wire transfer. The bank teller states the challenge of "Canary" and expects the response "Bluebird". Instead, the customer responds "Robin", and (according to the information in front of the teller) this secretly tells the bank teller that the customer is under some sort of duress - family member held hostage, gun to his head, etc. Things proceed as normal but the bank knows to consult the FBI, police, etc.

I know we can do secure, encrypted communication to pass around these challenge/responses. Social engineering relies on getting access to things without having the proper tools to do so (physical keys, keycodes, passwords). A stronger system of signs/countersigns can largely prevent this along with employee training.

My explanation was shite but I'm really tired and I'm not honestly sure that I could do better in the morning. I hope I've somehow managed to convey at least something useful to your question.

Great answer and points made well

[LostMyBeaver]

I often make the mistake of using words improperly and in this case, I more than likely am interchanging ISAM with another word having fully believed ISAM is that. Therefore I concede that there can be a fully logical flaw based on misuse of the term. The way I see it from my perspective is that an ISAM is the datastore itself, a series of tables and indices which can be used for efficient searches when the index corresponds to the search. My experience with DB/2 is that this API (especially in COBOL) is incredibly efficient and when indices exist for the searches of interest, it far better than an SQL front end which, while capable of making use of indices as well, generally is used on a more generic level. I would imagine that modern SQL implementations will work in a similar fashion to a tracing JIT and automatically produce index caches implicitly instead of explicitly for performance reasons on searches which are common. Instead of referring to the data store of DB/2 as an ISAM, there is more likely a better wording that can be chosen. However, the APIs provided by DB/2 that I also imagine are the APIs used by the SQL front end, meet the requirements of a relational database.

C has no I/O capability and no memory management which is precisely the problem with C. You find yourself reinventing the wheel over and over and over again. This leads to huge amounts of insecure code. I am willing to believe that most IP stacks today are about 99.9995% secure, I am even willing to believe that much of the more popular C based web servers are as must as 99% secure. But, the insecurities that are left tend to be the kind which when they're exploited are used to provide root access to the operating systems they're on. I won't say that Java or .NET is more secure, but I would say the sandbox they provide makes the playground the hacker has to make use of substantially smaller and less critical.

You're example of "can you do in C what COBOL does in 64 lines?" using a proper library... yes. C differentiates between the language and the libraries that are used. So, if I had a C library designed for database manipulation such as one I recall using many many moons ago though I can't recall the name... sure no problem. And as a result, I can have shitty code which is more than likely full of bugs. And while COBOL does have an I/O library and I admit it does function on machines with a true console, it's more likely to make use of the "Screen section". Which I have to admit I kinda forgot about since I've never used the "screen section" in COBOL as I've always used third party UI systems.

The important thing is... when you're making a UI in COBOL using the screen section, you define a set of fields and validation syntax etc... which is all possible using third party libraries in most other languages, but for the most part, in COBOL, you either use the screen section OR you use another language or utility for UI and COBOL becomes for the most part, the equivalent to the controller in an MVC paradigm. This is what I like best about it.

To me I really for the most part don't care which language is used specifically, so long as the run time is thoroughly sand boxed and for the most part crippled. COBOL offers this kind of sandbox whether due to limitations in the language itself or due to limitations in the environment. And yes, I know you could theoretically do everything in COBOL you do in C... it would require huge amounts of hackish code and simply calling a C function from the COBOL would be far more intelligent. Of course, in a database environment, this would be a pretty bad idea.

I stand by ditching TCP/IP... as I sit here implementing an OSPFv2 protocol handler for a device I'm working on. I have far too much respect for the flexibility of the IP stacks on many systems to trust them completely. And I stand by replacing it using message passing via MPI over Infiniband or just about anything else.

1) People know IP and know how to hack it. So you gain a great deal of securit

Re:Great answer and points made well

[LordActon]

I think we've arrived at something like agreement on the DBMS point. FYI SQL query optimizers are very different from JIT compilers. The basic reason is the 3-6 orders of magnitude difference between the speed of the CPU and that of the I/O. Index creation is too expensive and slow to be done dynamically to answer queries.

I agree that for all its faults COBOL makes screen handling easy. I don't remember the syntax anymore, but it's stupifyingly easy to read/write the fields by name on a form. I've never seen anything so, um, simple in GUI programming or web programming. And I wish the folks who developed HTTP/HTML had heard of a Communication Area and pseudo-converstational connections.

You actually can't do in COBOL everything you can do in C because it lacks explicit pointers. Without pointers you can't reference arbitrary locations in memory. That's why the only CICS system I ever designed had an assembler module for the non-standard stuff.

As for ditching TCP/IP, while I don't doubt Infiniband has its place, your reasoning has a few problems.

1. Security-through-obscurity is thoroughly discredited. At least, Whitfield Diffie thinks so. David Wheeler's book is online and not a bad place to start if you want to update yourself on security.
2. If you think "most IP stacks today are about 99.9995% secure" and you (implicitly) agree with my argument that bug counts decrease as code is used, why do you think your infiniband stack will be better?
3. Using IP doesn't automatically mean the webserver is connected to "the network". That's a design descision. Nothing prevents segregating the networks.

Widely used, well tested software such as your IP stack is bound to be more secure than whatever you would replace it with, despite the fact that the attacker knows what you're using and may even have the source code to it.

If they hacked the security on the web server through IP, they can very likely find a way to hack the security of the database server using a similar exploit.

That's a big if. I don't know what "99.9995% secure" means (what the denominator?) but I don't believe there's ever been an exploit via the TCP stack. It's one of those highly improbable events that, if it ever did happen, would suddenly subject millions of machines to attack. Your database server would be the least of your worries.

Nearly infinitely more likely, I'm sure you agree, is something much more pedestrian: social engineering, MD5 leaks, etc. Whatever it is, it doesn't follow that the same vehicle will exist on the DBMS host, nor should it.

Finally, since we're both fans of simplicity in programming, I leave you with this:

There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
— C. A. R. Hoare

Re:Great answer and points made well

[LostMyBeaver]

"You actually can't do in COBOL everything you can do in C because it lacks explicit pointers. Without pointers you can't reference arbitrary locations in memory. That's why the only CICS system I ever designed had an assembler module for the non-standard stuff."

Yep... this is where I refer to it as a crippled and retarded. To a minimal extent, though far less in modern times through pragmas and extensions, C is the same. You for example wouldn't generally write the boot loader or that task switcher of an operating system in C (though I figure you could today, tcc is quite nice) and of course boot loaders are less of an issue with the introduction of EFI. So I'd say that the register push/pop operation of a task switcher is likely still best done at least in inline assembler in C, but still best done in assembler. COBOL, I guess in theory could do most things without dropping to 370 assembler (or balrog as I liked to call it in the day), but even the COBOL vendors who added extensions to do more things haven't gone so far as to add inline assembler as far as I know :) This is a great benefit of COBOL.

I actually like this quite a bit about modern C# and .NET in general with regards to the "unsafe" code block stuff. In a way, I'd like to see an extension defining how unsafe a given piece of code might be. This allows .NET to be used for writing operating systems (most of one anyway) but still keeping most code pretty well sandboxed. Metro apps will be even nicer as Microsoft is pretty much blocking most system level access without proper permissions. Though this leads to the 'could you do in 64 lines....' being an issue again since needing to be explicit about everything in order to ensure secure code can quickly lead to people just explicitly allowing everything.

"Security-through-obscurity is thoroughly discredited. At least, Whitfield Diffie [zdnet.com] thinks so. David Wheeler's book is online and not a bad place to start if you want to update yourself on security."

Security through obscurity is discredited if you're simply trying to make insecure code secure by obfuscation or hiding things. On the other hand, having two different types of stacks with two different types of security makes hacking require a greater amount of effort and knowledge. If both stacks are almost 100% secure but their holes require two different exploits, then the obscurity is there not to completely secure the system, but to make whoever is hacking it have to work harder for it.

"If you think "most IP stacks today are about 99.9995% secure" and you (implicitly) agree with my argument that bug counts decrease as code is used, why do you think your infiniband stack will be better?"
- and -
"That's a big if. I don't know what "99.9995% secure" means (what the denominator?) but I don't believe there's ever been an exploit via the TCP stack. It's one of those highly improbable events that, if it ever did happen, would suddenly subject millions of machines to attack. Your database server would be the least of your worries."

I've been working on LWIP recently which is one of the most widely used IP stacks on the planet. And given the style of coding in the stack, I have to say, I don't believe that it can actually be secure. There are some obvious weaknesses in the code that I feel could not be removed without a full rewrite. I've worked on the Linux stack before as well and while it is considerably better, there is a great deal more complexity in the stack and given the scale of the complexity, I believe that there are still holes that haven't been found or exploited yet. Though I do believe some creative hacker will find them in due time. Also given the massive scale of the IP stack in Linux, I believe that changes can't be easily made to the stack without risking opening up holes in it. This is less of an issue for patches maintained by the kernel teams themselves, but I feel that patches that are applied as part of debian, ubuntu, redhat, etc..

You misunderstood my point

[IBitOBear]

When you put the session ID in a cookie you are compliant with my point of _not_ putting data in the query string (stuff after the "?" in the URL).

Then you double-down by ensuring that there are no GET pages/requests that allow any sort of data write. By this I mean, for example, wiring up your CGI such that if REQUEST=GET then you scrub our or fail all requests that could save data anywhere in your system.

Finally (though not clearly mentioned) the retrivial of most key non-public data should start with the POST of a form requesting that data as opposed to a GET request with a query. This isn't usually all that frame-friendly but it is much better as a security model. Worst case, you should use a subsession ID that has a lifetime of only a few seconds (tops 30 or so) that is created in response to the post and dies after one use so you can pass it through a nested GET.

But the short rule is "if you wouldn't want it published in google search results, it should not be data that can be reached via a GET query string".

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

[dkf]

A webserver running in a user-account, installed without being root, with a stateful doing the transparent redirection to/from non-priviledged port, a shell for that user set to /bin/false, a sandbox, non-loadable kernel modules, etc. can bring you a system that is immune to patching for *years*.

Good advice. A step forward from that is to run the webserver on a machine that has no write access to any filestore at all. Thus you send logs off-host, mount the things being served read-only from a networked filesystem (AFS is better for this than NFS because you can arrange for none of the users to have write capability to the remote filestore), and use multiple separate databases (obviously not on the webserver machine) so a hole there won't hurt (also give the DB users the minimum access rights that they need). Like that, any attack has to be strictly limited to altering memory and it is extremely difficult to inject substantial new trouble (like a rootkit).

And if you can disable PHP, so much the better. (Sure, you can write secure code in PHP, but community practice tends to insecurity and that's just more trouble than can be ever justified. Other languages much more strongly encourage Doing It Right from the beginning.)

[Almost] everything that you should know ....

[PositiveZero]

The following URL contains a comprehensive list of topics that should help you build your hardened web application :) http://programmers.stackexchange.com/questions/46716/what-should-every-programmer-know-about-web-development