Slashdot Mirror
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?"
I guess we'll just halt all human endeavor, since each of us doesn't know how to do every possible thing.
Moron.
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?
For some reason, every bank we deal with (for large business types) is internet explorer only. I guess you'll have to start there.
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.
Why harden your web app when you can just write in your EULA that end users can't sue you? Profit!
sysadmins and parents of newborns get the same amount of sleep.
and turn off the computer... and hopefully that will keep your data secure :)
Never antropomorphize computers, they do not like that
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'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.
I do not fail; I succeed at finding out what does not work.
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.
Read radical news here
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.
my mom posts on slashdot.
Also read The Web Application Hacker's Handbook. (google: wahh)
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.
Read radical news here
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.
FATMOUSE + YOU = FATMOUSE
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. 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.
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
http://saveie6.com/
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.
Check OWASP: http://www.owasp.com/index.php/Main_Page
Also, budget for an engagement with professional penetration testers. Best they find the holes before the black hats do.
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
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.
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.
Banks are clueless about internet security too!
How many are still using TLS v1.0?
How many are still insisting on limiting password lengths?
Exactly how does a "site image" add to any security? I've never seen any image other that the "good" one for logins. Idiots.
On to the real answer to your question.
* Don't use apache as a front end.
* Don't use Php, Python, ruby at all.
* Don't allow any user inputs to be passed to any DBMS without extremely strict filtering.
* Patch constantly.
* Have redundant systems in different states.
* Have monthly security audits performed by qualified pen-testers.
Or you can outsource everything and put penalties into the contract to protect your company from liability. "Indemnify" is the word you seek, young Padawan.
You 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.
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.
---------
Thinking never hurt anybody --MacGyver
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.
Did you just recommend a secure software book that you haven't even read...?
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.
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.
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).
All the world's a CPU, and all the men and women merely AI agents
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.
Take off every 'sig' !!
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.
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.
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.
Take off every 'sig' !!
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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.
#DeleteChrome
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.
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.
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.
... 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.
now we need to go OSS in diesel cars
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.
Explain this to Sony and Citybank.
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.
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.
AccountKiller
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.
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.
Yeah, I also like the "Red Black" concepts and wikipedia has quite a nice article on
http://en.wikipedia.org/wiki/Secure_by_design
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).
Slay a dragon... over lunch!
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.
[Fuck Beta]
o0t!
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.
I've fallen off your lawn, and I can't get up.
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.
- David A. Wheeler (see my Secure Programming HOWTO)
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.
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...
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.
Well, that doesn't say much for your family because it was rather easy to socially engineer you mom's pants off
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Reading is a wonderful thing. The poster asked for resources to learn, which is how one acquires the knowledge you're referring to.
The best thing about a boolean is even if you are wrong, you are only off by a bit.
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...
David C. Baird theunspokenyes.com
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.
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 ......
It's simple never trust the user. All inputs must be checked and sanitized.
"GET / HTTP/1.0" 200 51230 "-" "Mozilla/4.0 (compatible; Setec Astronomy)"
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.
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!
David C. Baird theunspokenyes.com
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.
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."
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?
Michael J. Ryan - tracker1.info
Yes, but it did have a lot of positive reviews.
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.
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.
SpyDock: Scientific Python in a Docker container
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.
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/.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
and Linux Firewalls
David C. Baird theunspokenyes.com
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 : )
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.
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.
Contrary to the popular belief, there indeed is no God.
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.
Java
[almost] end of story.....
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.
Advice: on VPS providers
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.
Contrary to the popular belief, there indeed is no God.
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.
Serious? Seriousness is well above my pay grade.
Try putting "book review" in the Slashdot search box and see if it comes up.
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
A few guidelines.
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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.
Write boring code, not shiny code!
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.
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.
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.
[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.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Actually implementing the security dev lifecycle is a good starter. At minimum create some threat models and identifiy the attack vectors and targets.
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.
world was created 5 seconds before this post as it is.
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)
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.
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
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
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.
It is dangerous to be right when the government is wrong.
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.
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.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
"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...
Random Thoughts From A Diseased Mind (Not For Dummies)
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.
Take off every 'sig' !!
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.
It's The Golden Rule: "He who has the gold makes the rules."
"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.
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.
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.
- 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 :-)
Don't Panic!
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.
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
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.
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.
Slay a dragon... over lunch!
Use peer-reviewed, open crypto algorithms where possible. (including hashing, key exchange, bulk data encryption)
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
You can't handle the truth.
...in a bank. My answer to this:
Also check out the Web Application Attack and Audit Framework at https://community.rapid7.com/community/w3af
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.
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.
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.
Check out my world simulator thingy.
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.
Check out my world simulator thingy.
I prefer an even number, for ease of decryption.
Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
are a good start.
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.
Contrary to the popular belief, there indeed is no God.
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.
Contrary to the popular belief, there indeed is no God.
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.
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.
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.
No, I will not work for your startup
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!
Contrary to the popular belief, there indeed is no God.
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.
who let the kids in here?
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.
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.
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.
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
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.
Contrary to the popular belief, there indeed is no God.
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.
(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.
Random Thoughts From A Diseased Mind (Not For Dummies)
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.
.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.
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
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
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".
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
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.)
"Little does he know, but there is no 'I' in 'Idiot'!"
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