Website Security Without Breaking the Bank? 195
An anonymous reader writes "I do my own Web design and have a few websites — MySQL, PHP, CSS, HTML, that kind of thing. It's simple, amateur stuff, but I would love to have some reasonable ways to assess their security myself and patch the big holes, or possibly enlist someone to do 'white hat' work to assist me. I have absolutely no idea how to proceed. I don't want to get mired in a never-ending paranoia-fueled race to patch holes before the hackers find them, but on the other hand, I don't want my websites to look like Swiss cheese. Right now, I wouldn't know what kind of cheese they look like: Swiss, Havarti, or hard as Parmesan. How can I take reasonable steps to protect these websites myself? What books has the community found useful? What groups (if any) can offer me inexpensive white-hat hacking that won't end up costing me a first-born child? Or am I better off just waiting until a problem arises and then fixing it?"
Well, for starters... (Score:5, Funny)
What's the URL? ;)
Re: (Score:3, Funny)
Re:Well, for starters... (Score:4, Informative)
Re: (Score:2)
Re: (Score:3, Informative)
I spent more than a year playing this wargame and learned a great deal about security.
The real world examples are the best. IRC can degrade into a flame war so you may not find much help there, alot of back patting.
eEye has some decent free tools, and useful Whitepapers.
http://www.eeye.com/html/index.html
Security Focus
http://www.securityfocus.com/
What toolkit would be complete without an excellent reference site. Includes some POC on some exploits.
SQL Injection White Paper from SPI Dynamics. Though I couldn
Attack with all your might .. (Score:5, Funny)
http://127.0.0.1/ [127.0.0.1]
Enjoy.
Re:Attack with all your might .. (Score:5, Funny)
Wow, I didn't know so much porn could be so free.
Some of the models look a little young though, are you sure they are all legal at that site?
Anyways, thanks for the tip.
Re: (Score:2, Funny)
Bah. I already have all that, and I think I might have a bit more even.
I can't believe there's anyone out there as much into... erh... what was that IP again?
Re: (Score:2, Insightful)
Ha ha! Your comment was not ranked as "funny" :P
Re: (Score:2)
It's inciteful. That's good enough.
No, that wasn't funny either. But dammit, it's NOT redundant this time! Ha!
if you wait until it happens... (Score:5, Insightful)
You still need to do homework. I realized a while ago that I not only lack a good understanding of potential weaknesses in my sites, but I also lack the knowledge needed to actually do the forensic log analysis if I was to actually get exploited. Along the lines of the original post, what good introductory tools are there that relate to forensic log analysis?
Re:if you wait until it happens... (Score:4, Funny)
Re: (Score:2)
A parmesan site will generally have issues of its own related to its crumbling interfering with functionality.
Not to mention everybody'll think your site smells like feet....
exactly (Score:5, Informative)
Honestly, if the OP is in the situation where he is trying to find and patch holes, it would probably be a better idea to do a little homework and start the project over again and use good security techniques when writing.
It is not that hard, really. You just have to remember never to trust user input. That means that you filter all of it, you don't rely on cookies for access control, and you don't trust the variables that the browser sent you (such as $_SESSION['http_referer']).
As far as filtering is concerned, remember that php has a lot of filters at your disposal [w3schools.com] (just remember to strip new lines out of email addresses yourself, the filter misses that one). Another word of warning: if you are echoing user input out onto a page, it is much easier to use bb syntax than allow html tags through strip tags: the danger is that an attacker can get javascript attributes the filter and it is better just to avoid it.
Comment removed (Score:4, Informative)
Re: (Score:2)
Infosec really is complex enough that it is almost impossible to do it right unless you make a career out of it. If you try to do it yourself, you will fail.
You have to hire a security expert to analyze your systems. Trying to do infosec "on the cheap" or DIY is like trying to do surgery on yourself. You attempt that and you wouldn't ask slashdot how to do that. Don't make the same mistake about infosec.
take a tour at OWASP site (Score:5, Informative)
Re:take a tour at OWASP site (Score:4, Informative)
Re: (Score:2)
Re:take a tour at OWASP site (Score:5, Informative)
OWASP is invaluable for learning the WHY and HOW behind security.
But for an amateur, I think the first best thing he could do is apply the Suhosin patch for PHP: http://www.hardened-php.net/ [hardened-php.net]
This lets him worry about the why and how AFTER he's already closed many of the attack vectors a default PHP install leaves open. Especially if he's running below 5.2.x.
Furthermore, PHP has been more security focused since 5.01. You can learn a lot about security just by reading the release notes, even if you don't think you're learning about security!
For example, the filter_input() function. Instead of doing this:
$phone_number = $_POST['phone_number'];
do this:
$phone_number = filter_input(INPUT_POST, 'phone_number', FILTER_SANITIZE_STRING);
That simple change applied to all of your $_POST, $_GET (and/or $_REQUEST) look-ups will shut down most of your application-level attacks.
Any PHP developer should learn and ALWAYS use the new Filter features: http://us2.php.net/manual/en/ref.filter.php [php.net]
Re: (Score:2)
I'm glad I've always used a wrapper function of some capacity for the $_POST, $_GET and $_FILE input methods.
When I learned of filter_input all I had to do was slap it in the wrapper functions... versus going and changing every call to a much larger, more complicated function call.
Re:take a tour at OWASP site (Score:5, Insightful)
Um, no. Parameterized queries are much safer.
Re: (Score:2)
Ok, i'll bite... what makes them safer?
The only real safety issue with mysql_real_escape_string() is that you could forget to call it.
Past that, if you pass every param thru that function, you're safe from injection attacks.
Better tools, good process, learning from others (Score:2, Insightful)
You can write insecure websites using pretty much any tools, but if you're using MySQL and PHP, especially if you're using other peoples code in your app, you're probably going to end up with a security nightmare, regardless of how hard you try.
It's possible to write secure code in PHP, but almost nobody does, and most of the PHP code that you can acquire easily is painfully insecure. A never ending race to patch a never ending series of holes means you've already failed at security. Depending on "white-hat
Re:Better tools, good process, learning from other (Score:5, Insightful)
It's possible to write secure code in PHP, but almost nobody does, and most of the PHP code that you can acquire easily is painfully insecure.
Writing secure code with PHP is no more harder than with Perl/Java/Ruby... same rules apply. I would even say nowadays it's extremely easy - use PDO with prepared queries, and you've pretty much eliminated SQL injections. Don't reinvent the wheel - for example Zend Framework is pretty cabable and done most of the work for you which you'd probably end up doing.
In a nutshell:
Validate your goddamned data. Use prepared queries to prevent SQL injections. And so on. The language used itself has very, very little to do with security in the end.
Re: (Score:2, Informative)
Re: (Score:3, Informative)
I have a simple guide when I write code, it's not flawless but it covers a lot of bases - every time I load a variable that has anything to do with generated content (i.e. from a user) I sanitise it - I don't report errors, I just strip out invalid characters (as a rule). It's not the best way to do it, but combined with a good site design it helps a lot.
Re: (Score:2)
In a nutshell: Validate your goddamned data. Use prepared queries to prevent SQL injections. And so on. The language used itself has very, very little to do with security in the end.
Stored procedures are also good ways to avoid injection attacks...
Re: (Score:2)
He said MySQL, so no stored procedures unless he's running > v5. I don't know what the penetration is for MySQL 5 in the hosting market.
With PHP and most PHP-based Web sites stored procedures are overkill. Use ADOdb [sourceforge.net] or PDO and you'll get similar protection with less hassle.
Re: (Score:3, Funny)
You can write insecure websites using pretty much any tools, but if you're using MySQL and PHP, especially if you're using other peoples code in your app, you're probably going to end up with a security nightmare, regardless of how hard you try.
Taken to the extreme you could prepare you own active page servlet using FORTRAN and obfuscate the binaries, randomize query url generation, and run everything on your server through a microkernel operating system where you change all of the system calls and commands to things only you know.
Then operate your website entirely anonymously with tenneling through tor between your actual webserver and the server putting up your domain.
Re: (Score:2)
FORTRAN: The RealUltimatePower?
Seriously, though, if you're really, really intent on obfuscating the code, why not C-Intercal through CGI? Link! [muppetlabs.com]
Sure, there are some minor performance hits, but it's hard to get more obfuscated.
Re:Better tools, good process, learning from other (Score:5, Interesting)
You can write insecure websites using pretty much any tools, but if you're using MySQL and PHP, especially if you're using other peoples code in your app, you're probably going to end up with a security nightmare, regardless of how hard you try.
That's the problem.
Most of the pros on here can write good-quality, secure code, in PHP, RoR, whatever.
It's the external libraries which are the gap. For example, look at phplist, which is used in many places [softpedia.com]. Now, every installation of it needs to be upgraded. Now. Right now.
Unless you're a 100% fulltime sysadmin, you haven't got the time to be reading the security lists hourly and upgrading phplist etc when required.
The OP is really asking: how do I make sure phplist and the other hundred Ruby gems or PHP add-ins are up-to-date and safe? And keep them that way?
Re: (Score:2)
Re:Better tools, good process, learning from other (Score:5, Insightful)
The problem is that MOST sites that get 0wn3d are running phpbb or other very common and popular packages. They are getting better but they are still the most hacked because it's easy to identify what your site is using and then go and find the exploits for that site.
the SAFEST is typically custom code. and go NUTS on everything that comes from a user treating it like it's a bomb every time. It causes the kiddie to take a LOT of time to crack you, they typically move along for easier fields quite quickly. Back in the early 2000's I used to taunt the "crackers" and "kiddies" if you tried banging on my telnet or ssh door, you were actually banging on my taunt the L0ser door. It would insult the hell out of them and make them think their bot got in because it would give a successful login every time and then taunt the hell out of them and "logoff" I had a single little turd in chicago banging on me for a month until he got his buddies involved and they DDOS attacked my box with all of them trying to attack 120 bored kiddies can bring down a T1 fast, it lasted for 3 days. Funny part was 4 of them was doing it from home and when I personally called their parents all the attacks stopped. (They were on Comcast cable modems and I worked for Comcast at the time so I got the customer contact info quite easily.)
You more than likely do not have the resources I did, so dont provoke them. Taunting the lions is fun, but they now have an army of robots.
Step 1 look through you logs DAILY. 99.999782% of all website admins do not do this. Sorry but you cant spot strange things without going through logs. get a parser that makes it easier, but do it.
Step 2 learn to write secure php code and then write your sites scripts custom. Got a mailer for a contact us page? HARD CODE the to: address and get ready for the never ending fight to filter out spam.
Step 3 Backups.. never TRUST a backup you make from the site, your only real backup is the files you created and uploaded.
Step 4 review everything monthly go over stuff, look for broken or strange, go over all of it.. Look there's a wierd file in your ftp area.. how did that get there?
If you are running phpbb or drupal or other "popular" scripts you needto update them weekly. phpbb has patches all the time and MOST dont get applied by sites that get cracked.
Look at OWASP for Top 10 security vulnerabilities (Score:5, Informative)
The Open Web Application Security Project (OWASP) has a Top 10 list, which lists the most serious web application vulnerabilities, discusses how to protect against them, and provides links to more information (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project [owasp.org]). This might be a good start.
A book couldn't hurt (Score:5, Informative)
I learned a decent amount from Essential PHP Security [is.gd]*. It doesn't cover everything, but should cover most of the crazy-stupid errors that crop up in a lot of novice php/mysql stuff. Not that the information isn't out there in plenty of places (just like every other topic humanity has ever thought up), but for twenty bucks it's nice to have a hard copy of the essentials in one place.
*Yes, that's a referral link to amazon. But I'd recommend it either way for people getting started with securing their basic LAMP sites.
Re: (Score:2)
Re: (Score:2)
Does anyone know the difference between these two books?
http://www.fishpond.com.au/Books/Computers/Internet/Security/product_info/915276/?cf=3&rid=1774576082&i=1&keywords=0-596-00656-X [fishpond.com.au]
http://www.fishpond.com.au/Books/Computers/Internet/Security/product_info/3625450/?cf=3&rid=1774576082&i=3&keywords=0-596-00656-X [fishpond.com.au]
The ISBNs are the same but page counts are different. I was just looking around for a cheaper price. (Buying and shipping from Amazon will be around $45 for me (up to 32 days
Learn good coding practice (Score:5, Informative)
It doesn't matter what you do after the fact to secure your web sites, if your scripting is full of holes, trying to plug them up after the fact isn't going to work. For example, you mention MySQL so I gather your code accesses one or more databases? If so do you know what a SQL injection bug is and have you reviewed your code for them? Nothing you do at the point of deployment is going to help fix a SQL injection bug.
I'm afraid that if you're using MySQL and PHP you've moved from the realm of the very basic to something more advanced. You're no longer just talking about slapping static content on the web. People spend years learning how to do these things really well. You should find yourself a good book and get started. Start with a Google. It costs nothing. If you have friends who do web development with similar tools talk to them and see if they'll help point you in the right direction.
Here are some things to get you started. Note that these are language independent things you should do no matter what dev tools you use. You might want to look at something more targetted for PHP as well.
https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices [cert.org]
Here's the main site.
https://www.securecoding.cert.org/confluence/display/seccode/CERT+Secure+Coding+Standards [cert.org]
The other way to go would be to make your web files more static. However getting rid of everything dynamic may not be a reasonable option in 2009.
Good read (Score:2, Informative)
http://www.ipa.go.jp/security/vuln/documents/website_security_en.pdf [ipa.go.jp]
It's quite easy to understand and if you follow all the recommendations your website should be more secure than average.
Re: (Score:2)
http://www.ipa.go.jp/security/vuln/documents/website_security_en.pdf
This looks like a very good tutorial on the basics of web security. I think I'll forward it to some of my *ahem* Less-than-brilliant web admin friends.
mod_security (Score:5, Informative)
Re: (Score:2)
Yep and also look up SELinux.
If you use other peoples apps, stick with popular open source ones and keep the patches up to date. Be wary of using copypasta code.
If you write your own, escape your inputs. Better yet to validate them with regex and use place-holders in your SQL.
Re:mod_security (Score:4, Informative)
Also, take a look at installing Suhosin [hardened-php.net], if you have root access to your server. It's a PHP patch that adds more security on the binary level to combat certain common attack vectors like SQL injection (though that said, you should never simply rely on its protection without knowing how these attacks work and how to program defensively).
Speaking of which, PHP itself has a page on SQL injection and how to avoid it [php.net], which I recommend that you read and commit to memory if you don't already know about it. Especially for new developers in the PHP world, SQL injection is the number one security pitfall, and if you're uneducated about it, it's very easy to create insecure applications.
If you would like, I am a very experienced developer with about eight years of PHP experience. I can go through your code with you and tell you where you might be able to improve security. My rate is $30 / hour, but it probably won't take too long to give recommendations. If you're interested, please contact me at my first name at jamiearseneault.com.
Re: (Score:3, Informative)
> I recommend mod_security
One thing to watch for with mod_security is that it will block certain requests even when it's in 'logging only' mode [blogs.com]. Still a useful tool, but keep a close eye on it.
It's Simple Really You Pay Someone Who Knows How (Score:4, Insightful)
Either you spend the time to teach yourself about security.
Or you pay someone to do it for you.
Re: (Score:2)
+1 to the above. Like anything else, you pay for someone else's expertise, or you learn yourself.
The best and most through guide to web testing and security out there is to the Web Application Hackers Handbook [amazon.com], but the OWASP Testing Guide is a good intro and a free download you can start working with today.
PDF version [owasp.org]
Main page [owasp.org]
The best way to learn is by doing, and OWASP WebGoat is a good interactive learning environment. It's also quite easy to try out using the OWASP Live cd [owasp.org], which has many of t
Re: (Score:2)
This in response to a question that could be summarized as "Where can I learn more about security or find someone to teach me at a decent rate?"
Best strategy (Score:2, Insightful)
Re:Best strategy (Score:5, Informative)
Point is, he writes his own PHP. It's very easy to include URL parameters into a query string, don't validate input for mail() et cetera. He needs someone to tell him where is PHP is wrong.
Some of these replies are pretty vague (Score:4, Informative)
In that case, the biggest exploits that you are probably easily vulnerable to are SQL injection and JavaScript injection. I highly recommend that you research those two things, they will go a long way toward securing your website.
The Kaspersky anti-virus website fell victim to SQL injection just yesterday... but it is an easy thing to prevent with a little knowledge and diligence.
Re:Some of these replies are pretty vague (Score:5, Informative)
The easiest way to prevent SQL injection is to use a library like MBD2 ( http://pear.php.net/package/MDB2 [php.net] ) and use placeholders.
That way any data you use in SQL statements is automatically quoted.
Perl users have had this for ages with the DBI module, so SQL injection is much less likely in Perl than in PHP. Hackers like PHP ;)
Also AFAIK PHP has no convenient way of stripping Javascript from user input which also creates a risk.
X.
Re: (Score:2)
Re: (Score:2)
Developers starting a new application would do well to begin with a PHP framework [wikipedia.org]. No, frameworks don't solve every problem. Yes, some of them suck or are only suitable for certain kinds of sites or applications. But with all of the options out there, there's bound to be at least one that suits your needs and gets you started on the interesting parts of the code sooner. (I like CodeIgniter, for instance.)
T
Re: (Score:2)
I'll look into that sometime. I've built enough PHP stuff already without a framework to be comfortable without one, but I recently got into the jquery javascript framework and that was a very pleasant experience compared to plain javascript.
Maybe CodeIgniter would provide a similar experience to plain old PHP.
X.
security through backups (Score:4, Insightful)
- very very imho -
backups don't help your users who might be attacked by your compromised sites but the ability to wipe the bad and restart is great. requires multiple levels of backups, daily, weekly, monthly, all separate.
You can't restart immediately, presumably you'll get nailed by the same exploit when you recover, but at least you'll know there's a specific problem - finding something specific is nearly always easier than finding something general.
also, control your URLs. controlling what can be passed to your site controls a hell of a lot of security problems.
lastly - make sure your logs are good and safe and verbose. if you pay attention to making the logs right, when you have a problem, you can find someone to review the logs and find the issue. if you don't have the logs, well. you're more screwed.
Do those three things and some common sense when coding and you'll be better off than most. Security is always where you draw the line, personally I like it a bit ahead of the curve but no where near perfect.
Learn from the best (Score:2)
I'd do the following. Put your code in Subversion or some other version control system. Find someone (maybe in your environment, maybe on Elance [elance.com]) who does this sort of stuff for a living.
Pay him to check out the code of your sites and your databases. Let him save his changes in your version control system, then go look for yourself to see what he changed. Reserve an extra hour of face or phone time with the guy to walk through all changes.
Automate it (Score:2, Interesting)
Some Ideas (Score:5, Informative)
First and foremost, check and sanitize EVERY input passed via a $_POST or $_GET (and to be safe, check cookie inputs too).
Make SURE that none of them are in a format or contain data that you don't expect.
It is easier said than done, and it sucks major ass to do, but it's really the only way to be sure of what you are doing.
I just spent most of the last week tracking down an XSS exploit for a client, and it was a mother to find where to filter the input AND what to look for. SOME inputs needed SOME HTML tags to pass through, others required binary data, and still others needed integers.
My advice on new code is to check your inputs like crazy before assigning any submitted data to a variable. Then check the variables themselves.
Watch for hex encodings of HTML characters, and then watch for it again.
Then, after all that work, hope it works, then drink heavily.
Re: (Score:2)
Make SURE that none of them are in a format or contain data that you don't expect
Step one: Make sure you know exactly what data/format you DO expect. The tighter you specify the accepted format and data structure, the easier it will be to test the data. (E.g., if the client is designed to submit a phone number as an integer with 10 to 15 places, and you get a 40 character string with alphabetic characters, spaces, and punctuation you know something is up). Obviously don't rely on client scripts to validate the data before submission.
Re: (Score:2)
Obviously don't rely on client scripts to validate the data before submission.
This is, in my mind, one of the most important things. To go a bit further, don't rely on the client to do anything. Just because you restrict a certain field on a form doesn't mean that's all a client can submit. I would suggest learning the http protocol (the basic concepts are really not that complicated) and keeping that in mind every time you accept input from a user. (Along with everything else others have said - sanitize/validate input, use parameterized/prepared queries, and properly escape any
Re: (Score:2)
Amen. Don't block bad things; instead, allow known-to-be-good things. Anything not allowed, is prohibited by default.
Ask the experts (Score:2, Funny)
I don't get it... (Score:2)
Re: (Score:2)
PHP and MySQL aren't insecure per-se, it's just that people hack things together quickly with it that are insecure.
AFAIK PHP isn't vulnerable to buffer overflows directly. You have no control over pointers, so any stack overflows vulnerabilities have been in libraries, but exploited via PHP.
Standard MySQL functions in PHP don't support parameterized queries, but the MySQLi methods do, and MySQLi is installed on a lot of hosts these days. If it's not on a server then it's generally easy enough to add it.
The
Re: (Score:2)
For example PHP supports prepared queries and the like, but it also supports the execution of bare strings as queries. In my experience most PHP programmers started back before prepared queries and just use the strings.
Another example: register_globals [wordpress.com] -- a short read, but a good one.
So it's not like any of these things are inherently security breaches, but they do lead to them without jud
Suhosin, etc... (Score:5, Informative)
I just got back from a PHP security class, here's a quick overview of what was covered:
- register_globals = off
- Use the Suhosin PHP hardening patch.
- Always filter all of your input for injection attempts. Write a validation class to handle this.
- Use prepared SQL statements, or stored procedures to help avoid sql injections
There are some pretty good articles out there that cover most of these points and more, just google for "PHP security". Take the time to read the articles, they're worth it.
It's really sad that more people don't pay attention to PHP security. The class I took was, as far as I know, the only commercial PHP security class offered in the US this year, and there were only 4 students in attendance.
Re: (Score:2)
- Always filter all of your input for injection attempts. Write a validation class to handle this.
Why isn't there one built in to the language? Seems like something that damn well ought to be there.
Re: (Score:3, Informative)
All good points. I would add that you don't really need to filter your input for injection attempts. Filter your data for valid input. And don't ever use user-submitted content to create code to run. That means don't do it in your php code, and don't do it in stored procedures. If you absolutely MUST, be extra sure that it's validated, and then if it's a string where it's potentially legal to have something resembling sql code, escape it.
Enforce good passwords (Score:2, Informative)
Ensure your users pick good passwords [darkreading.com], by preventing them from entering passwords described here (e.g. their firstname, "password", "qwerty", etc).
80-20 rule (Score:4, Informative)
I'm not suggesting this is rock-solid security. It's a few easy steps that keeps most of the knuckleheads at bay.
Seth
Re: (Score:2)
This seems like a really good idea, and a no-brainer if it works well. But how do you ensure that you make no errors of type 1 (a fellow national can't view the site)? I'll want ALL of the residents of a few countries to be able to access the site, even if that means that a few others can access it as well.
Furthermore I have no idea what IPs hotels, mobile phone providers, offshore workers, restaurant chains and probably many more I haven't though of will give their custo
Re: (Score:3, Interesting)
When I think about it it's probably not very prudent to do, since you'll never be able to fine-tune it enough for most uses. You'd never know either if the customer didn't contact you in other manners.
I would hate for my client to lose business because legitimate customers can't access their site. I'll just put my faith in the provider's update routines and my own code :)
You are well and truly f'd. (Score:2)
Especially since you seem to want to patch holes when you find them instead of designing your code with security in mind. If you do not learn about security and secure programming, you will run into problems again and again. Even the "best" outside help will not be able to completely overhaul your insecure system if you regard security as something to be "patched in" instead of something to be designed for.
If you are going to wait for your sites to be compromised to figure out if anything went wrong (and le
simple, effective starting point (Score:5, Funny)
http://xkcd.com/327/ [xkcd.com]
tight security only slows 'em down (Score:3, Insightful)
Apart from speeding the recovery in case of a breaking/defacement it will also assist you if your hosting service goes bust, stops serving or you find someone else who's better / cheaper / has more facilities.
I'm not saying you shouldn't apply sensible security precautions, but don't treat them as if they'll make your sites impregnable. The ability to quickly restore a site means you don't have to go around checking each link on every page to see if it's been messed with.
WITHOUT breaking the bank? (Score:3, Funny)
The banks are already broken. Too late.
Security frameworks for PHP? (Score:2)
I know Java has a lot of different security frameworks like JSecurity or AcegiSecurity, but I'm not so sure about PHP.
No security experts in Slashdot then? (Score:2)
I have read most messages in this thread so far and the only thing I find is vague recommendations but nothing solid.
What we could all benefit from is:
- Specific book titles.
- Specific websites.
- Specific training (go on, if you are providing such training people want to hear from you).
The amount of vaguery posted so far tells me that people with a clue about security may not frequent this site or that simply there is no material out there.
I may have a business plan there somewhere ...
This is the internet - what do you expect? (Score:2)
Even taking the posts that get voted up is dodgy, as people tend to vote up things they agree with rather tha
framework (Score:2)
If you're on a budget (either time or money), use a framework that handles most of the problems for you. Why reinvent the wheel?
For PHP, there's CodeIgniter, Cake, and some others in the MVC area, and probably some outside. Google is your friend.
Why a framework? Because stuff like escaping your data before handing it to the database (to prevent SQL injection attacks), or sanitizing your input (to prevent XSS and other attacks) and so on are fairly simple things to do, you just have to remember to do them ev
Learn about security to get good web security (Score:3, Informative)
You can start here:
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/358-BSI.html [us-cert.gov]
And for specifically for web apps:
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assembly/639-BSI.html [us-cert.gov]
Then you frighten yourself by playing with the toys here:
http://insecure.org/ [insecure.org]
Static Analysis, Free Scanners, Books, Help (Score:2)
You should probably check out some of the open source static analysis tools:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis [wikipedia.org]
I wrote one that deals mostly with web applications:
http://www.yasca.org/ [yasca.org]
You should also get your hands on Acunetix Free Edition, which scans for XSS:
http://www.acunetix.com/cross-site-scripting/scanner.htm [acunetix.com]
Also grab yourself a copy of Software Security [amazon.com] by Gary McGraw and Secure Programming with Static Analyis [amazon.com] by Brian Chess and Jacob West.
Finally, if you want to outs
Try these (Score:2)
There are a number of web app security sites that will teach you how to test your website for security vulnerabilities. Even providing sample inputs for trying XSS and SQL-Injection attacks on your own site. Try these for starters:
http://www.owasp.org/ [owasp.org]
http://ha.ckers.org/xss.html [ckers.org]
Your enemy is the user. (Score:3, Interesting)
Or rather, the input your user gives you.
Let's leave aside non-web vulnerabilities for now - of course you'll want to use SFTP and SSH instead of unsecured FTP or Telnet to connect to your server, and HTTPS for your web admin panel, but these are outside the scope of the actual website - they're for your host to deal with.
When you write any kind of dynamic website, user input is the threat. Your website communicates via text with other layers such as the database (SQL) or the users' browser (HTML). Your two biggest risks are SQL injection (where user input breaks out of SQL quotes) and Cross Site Scripting/Request Forgery (where one user's input is executed as Javascript in another user's browser).
Another threat is performing actions (such as deleting/editing content) via GET requests, which will allow search spiders or content prefetchers to wreak havoc.
Two words (Score:2)
Pick up a LAMP for experts book (Score:2)
Any of the great LAMP books should have sections devoted to security. Each of the components has a part to play. The obvious vectors are PHP and MySQL so pay particular attention to those. If that's not enough, get a book for each... I'm certain there are "Security for MySQL" , etc.
They should all be available used on amazon for $10- $15 each... if $100 is out of your budget, then you'll need to start googling and doc diving.
Apache with mod_security is a good start (Score:2)
See subject.
From various posts (Score:2)
SethJohnson brings up two excellent points:
a) back up regularly. If you back up nightly then the most you can lose is a days worth of data. If you sync the backup directory (mysqldump cron job) to your local machine (I use lftp) then it's quicker than having to contact your hosting support. I disagree with H310iSe, just daily backups are fine.
b) don't install anything you don't have to. Disable all plug-ins you aren't using. If using somebody else's code Google it to see what problems other people are havin
Use a PHP framework (Score:2)
audit (Score:2)
The list of things you need to protect against is actually pretty short, provided that your list is high-level and general enough. ;-)
Look at this [ibm.com]. Most of that boils down to instances of trusting inputs, which is always a bad idea when the internet is involved.
Then audit your code and look for the mistakes. It is impossible to achieve your goal without d
Web App Hackers Handbook (Score:2)
brag (Score:2)
Brag about how awesome your site security is. Somebody's bound to take you up on the offer.
Simple (Score:4, Informative)
0) Use a version control system
1) Validate input, escape output
2) Turn off unused services
3) Regular, automatic backups to another location
Ok, the OWASP list is more comprehensive, but these four things are fundamental to preventing, and recovering from, security breaches.
Re: (Score:2)
0) Use a version control system
1) Validate input, escape output
2) Turn off unused services
3) Regular, automatic backups to another location
Ok, the OWASP list is more comprehensive, but these four things are fundamental to preventing, and recovering from, security breaches.
In particular, #1 means make sure that for any input your program receives (even HTTP vars like REQUEST_URI) the input is generally what you were expecting -- size, variable type, no unprintable characters.
And for every value your program sends out, whether to the server as an html response or to the database as an sql query or to the shell as a command line argument, use the proper means of escaping it so that special characters can't cause unintended consequences.
Re: (Score:2)
Re:Hi Slashdot (Score:5, Funny)
Re:Hi Slashdot (Score:4, Funny)
Buy everyone on /. a pony
I could do with the extra protein.
PCI certified .. (Score:2, Interesting)
All the PCI standard does is set down a number of criteria to be PCI certified. In the real world this provides no defense against getting hacked, as Heartland Payment Systems learned to their regret.
"This docu
Re: (Score:2)
Seconding this, and surprised that no one else has mentioned it yet. Nessus is a great, comprehensive external security tool with relatively easy-to-understand results.
Yeah, validating inputs and all of that is good, but it's ultimately useless if your version of Apache has a mod enabled that allows easy hijacking of the webserver itself, or if your OS is leaving other ports and protocols exposed as attack vectors.