Beta

Slashdot: News for Nerds

×

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

Thank you!

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

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

Website Security Without Breaking the Bank?

kdawson posted more than 5 years ago | from the man-who-is-his-own-lawyer dept.

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

cancel ×

195 comments

Hi Slashdot (1, Funny)

Fanboy Fantasies (917592) | more than 5 years ago | (#26794209)

3rd reply to this post tellsw me whag I should do tomorrow. As always, pictures will be posted.

Re:Hi Slashdot (-1, Flamebait)

Tubal-Cain (1289912) | more than 5 years ago | (#26794217)

Die.

Re:Hi Slashdot (1)

Tubal-Cain (1289912) | more than 5 years ago | (#26794227)

Use the Internet for the last time.

Re:Hi Slashdot (4, Funny)

Tubal-Cain (1289912) | more than 5 years ago | (#26794235)

Buy a pony.

Re:Hi Slashdot (3, Funny)

L4t3r4lu5 (1216702) | more than 5 years ago | (#26794929)

Buy everyone on /. a pony

I could do with the extra protein.

Re:Hi Slashdot (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26794973)

Suicide.

You should (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26795029)

commit suicide.

Well, for starters... (5, Funny)

Xenna (37238) | more than 5 years ago | (#26794213)

What's the URL? ;)

Re:Well, for starters... (2, Funny)

iammani (1392285) | more than 5 years ago | (#26794233)

slashdot.org :)

Attack with all your might .. (5, Funny)

cheros (223479) | more than 5 years ago | (#26794295)

http://127.0.0.1/ [127.0.0.1]

Enjoy.

Re:Attack with all your might .. (5, Funny)

sumdumass (711423) | more than 5 years ago | (#26794429)

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:Attack with all your might .. (1, Funny)

Opportunist (166417) | more than 5 years ago | (#26794465)

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:Attack with all your might .. (2, Insightful)

Anonymous Coward | more than 5 years ago | (#26794719)

Ha ha! Your comment was not ranked as "funny" :P

Amateur stuff? (0)

Anonymous Coward | more than 5 years ago | (#26794571)

This should be relevant to my interests. I too want the URL.

if you wait until it happens... (5, Insightful)

kamakazi (74641) | more than 5 years ago | (#26794237)

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

arogier (1250960) | more than 5 years ago | (#26794279)

Better to shoot for Colby Jack for the time being. A nice blend of cheeses that get along well enough to accomplish the sites purpose and conspicuously lacking in holes. A parmesan site will generally have issues of its own related to its crumbling interfering with functionality.

exactly (4, Informative)

an.echte.trilingue (1063180) | more than 5 years ago | (#26794589)

exactly right.

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.

take a tour at OWASP site (5, Informative)

hugetoon (766694) | more than 5 years ago | (#26794239)

Re:take a tour at OWASP site (3, Informative)

jofny (540291) | more than 5 years ago | (#26794343)

I second OWASP. Getting familiar with this and taking care of these issues if they exist currently and keeping them in mind when you write new code well get you a long way initially.

Re:take a tour at OWASP site (0)

Anonymous Coward | more than 5 years ago | (#26795459)

Yep, you should take a look at the OWASP Development Guide http://www.owasp.org/index.php/Category:OWASP_Guide_Project
but only as a starting point.

Better tools, good process, learning from others (2, Insightful)

SSpade (549608) | more than 5 years ago | (#26794261)

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 hacking", ditto.

Other than that... security is something integrated process, starting with the architectural design, the implementation and the processes around it, documentation and maintenance. It's not something you can just add on the side.

Books? No idea, but looks for stuff that talks about the entire lifecycle, and that comes from real world experience.

Oh, and learn some real crypto, so you can avoid both the snake oil and the irrational paranoia.

Re:Better tools, good process, learning from other (5, Insightful)

Anonymous Coward | more than 5 years ago | (#26794413)

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:Better tools, good process, learning from other (2, Informative)

Banacek (994201) | more than 5 years ago | (#26794635)

Agreed with everything you said. You could write your own classes to turn PHP into acting strongly typed, then sanitize your data after it's been type checked, but that might be beyond the scope of this project. Save yourself some hassle and read this too: http://devzone.zend.com/node/view/id/168 [zend.com] It will help validating those inputs.

Re:Better tools, good process, learning from other (2, Informative)

Architect_sasyr (938685) | more than 5 years ago | (#26795827)

Another useful read (albeit not focused on PHP per-se) is David Wheelers Secure Programming (http://www.dwheeler.com/secure-programs/)

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:Better tools, good process, learning from other (1)

Bonobo_Unknown (925651) | more than 5 years ago | (#26795973)

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:Better tools, good process, learning from other (3, Funny)

arogier (1250960) | more than 5 years ago | (#26794665)

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:Better tools, good process, learning from other (4, Interesting)

commanderfoxtrot (115784) | more than 5 years ago | (#26794749)

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:Better tools, good process, learning from other (1)

Yvanhoe (564877) | more than 5 years ago | (#26794903)

Seconded. Doing MySQL/PHP websites is indeed easy, but doing them secure is where the real challenge is. Without any knowledge of common flaws, your current architecture is probably already unpatchable and would require a rewrite to secure. I may be overly pessimistic but there are so many ways to botch it when you don't know much that it would a miracle that you don't rely on a flawed feature.

Have a look into ratproxy (0)

Anonymous Coward | more than 5 years ago | (#26794267)

Not only will it have a look at what you've got, but it's a good kick-off point to understand some of the pitfalls.

Look at OWASP for Top 10 security vulnerabilities (5, Informative)

mlgm (61962) | more than 5 years ago | (#26794271)

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

Firehed (942385) | more than 5 years ago | (#26794275)

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:A book couldn't hurt (1)

Kolargol00 (1177651) | more than 5 years ago | (#26794371)

I'll second this. Essential PHP Security [oreilly.com] is a good book to get you started in coding securely with PHP.

Re:A book couldn't hurt (1)

ribuck (943217) | more than 5 years ago | (#26795473)

You could start with O'Reilly's "Web Security, Privacy & Commerce [amazon.com] " by Simson Garfinkel. It's a good high-level holistic view. Then you can drill down to specific books or websites about PHP and MySQL security.

YOU FAIL IT? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26794293)

Learn good coding practice (5, Informative)

syousef (465911) | more than 5 years ago | (#26794303)

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.

Re:Learn good coding practice (0)

Anonymous Coward | more than 5 years ago | (#26796061)

You should find yourself a good book and get started.

That's the other problem. The majority of books on the subject of dynamic (esp. in PHP) websites are poorly written by clueless authors with flawed example code that continue to perpetuate horrific coding practices in the same fashion as the copy and paste, free script web sites.

Good read (2, Informative)

youcantwin (1459567) | more than 5 years ago | (#26794311)

Here's a good read with a checklist of things to do to secure your website from page 80
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.

mod_security (5, Informative)

'Aikanaka (581446) | more than 5 years ago | (#26794317)

I recommend mod_security and mod_evasive. A reverse proxy would help as well. The DoD and NSA have configuration guides that provide tips on securing Apache (as well as IIS).

Re:mod_security (1)

zobier (585066) | more than 5 years ago | (#26794817)

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

TheSpoom (715771) | more than 5 years ago | (#26795317)

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.

It's Simple Really You Pay Someone Who Knows How (3, Insightful)

phantomcircuit (938963) | more than 5 years ago | (#26794323)

Either you spend the time to teach yourself about security.

Or you pay someone to do it for you.

correction (1)

ILuvRamen (1026668) | more than 5 years ago | (#26794333)

Parmesean actually crumbles really easily. I don't think any type of cheese is really tough enough to protect your server lol. Maybe gouda cuz that's some tough, thick stuff but other than that, I'd suggest dousing a wall in gasoline and lighting it up. That would of course be a firewall lol.

Re:correction (1)

egcagrac0 (1410377) | more than 5 years ago | (#26795401)

Gouda is only tough because of the wax on the outside, IIRC. The cheese it self is fairly soft and melty. For resilient cheese, I think you need to look towards your 3 to 5 year cheddars and similar.

Best strategy (2, Insightful)

Shadow7789 (1000101) | more than 5 years ago | (#26794391)

Keep you MySQL only accessible via localhost, put a good password on it's root account, and make separate users for each database with access restricted to each one. I know it's important. Other than that, if you close ports you don't need , keep your software up to date, and write your own PHP I really don't think you have much too worry about.

Re:Best strategy (4, Informative)

cerberusss (660701) | more than 5 years ago | (#26794451)

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

Jane Q. Public (1010737) | more than 5 years ago | (#26794399)

but you asked about our applications, not your server setup. So my answer presumes that you are in a hosted environment and are trusting to your host to handle that end.

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

Xenna (37238) | more than 5 years ago | (#26794591)

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:Some of these replies are pretty vague (1)

Jane Q. Public (1010737) | more than 5 years ago | (#26794605)

That does present a problem. I am used to working in Ruby and Rails, and eliminating both SQL injection and JS injection is pretty easy. But you still have to take the trouble to do it.

http://www.snort.org/ (0, Offtopic)

boredhacker (1103107) | more than 5 years ago | (#26794401)

should help some

security through backups (3, Insightful)

H310iSe (249662) | more than 5 years ago | (#26794431)

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

Automate it (0)

Anonymous Coward | more than 5 years ago | (#26794439)

There are some good automated security scanners out there. For instance: Nesses/Nikto, WebScarab with proxmon, portswigger, and you can even go as far as using 3rd party companies such as HackerSafe.com or SecurityMetrics.com. Even though this doesn't give you a 100% fail-safe security scenario (*cough* nothing does and probably never will), it at least helps decrease the chances of common and even some more uncommon attacks such as SQL injections, overflows, man-in-the-middle attacks, etc.

You also obviously have to write secure code and keep all of your software up to date (especially open source software). This is not only true for PHP, but for all programming languages.

You should also try using BSD since you have a LAMP system.

Some other good sources of information:
http://www.webappsec.org/
http://www.owasp.org/

Hope this helps...

Learn from the best (1)

cerberusss (660701) | more than 5 years ago | (#26794445)

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 (2, Interesting)

jrozzi (1279772) | more than 5 years ago | (#26794447)

There are some good automated security scanners out there. For instance: Nesses/Nikto, WebScarab with proxmon, portswigger, and you can even go as far as using 3rd party companies such as HackerSafe.com or SecurityMetrics.com. Even though this doesn't give you a 100% fail-safe security scenario (*cough* nothing does and probably never will), it at least helps decrease the chances of common and even some more uncommon attacks such as SQL injections, overflows, man-in-the-middle attacks, etc. You also obviously have to write secure code and keep all of your software up to date (especially open source software). This is not only true for PHP, but for all programming languages. You should also try using BSD since you have a LAMP system. Some other good sources of information: http://www.webappsec.org/ [webappsec.org] http://www.owasp.org/ [owasp.org] Hope this helps...

SQL Injection (1)

rocketpants (1095431) | more than 5 years ago | (#26794467)

If you can prevent SQL injection attacks, you're already one step ahead of the "experts" at Kaspersky :o) Change all of your database access code to use parameterised queries (which in your case means MySQLi) and you've eliminated one of the major points of attack.

Some Ideas (5, Informative)

maz2331 (1104901) | more than 5 years ago | (#26794471)

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.

Safe time and money... (0)

Anonymous Coward | more than 5 years ago | (#26794491)

...and outsource the whole thing to some host. There are very cheap deals with great bandwidth and speed that take only little time. I used to put CMS myself onto root servers... then VPS and it was too much work and nobody cared.

Joomla may be a choice! (0)

Anonymous Coward | more than 5 years ago | (#26794493)

Security, massive capabilities and you can install free modules like chat rooms, blogs, calendars. You can also up/download files and display picture/video galleries.

If you want to sell stuff, it works as E-commerce too.

There is so much and it is so versatile, I have not run across anything I can't do yet.

Ask the experts (2, Funny)

Anonymous Coward | more than 5 years ago | (#26794529)

Kaspersky [kaspersky.com]

I don't get it... (1)

spiffmastercow (1001386) | more than 5 years ago | (#26794539)

How is PHP/MySQL so insecure? I write asp.net for a living (I'd rather write in python or C, but such is life), and I find it hard to imagine where these pages are so vulnerable. Is PHP vulnerable to buffer overflows the way old C code is? Does MySQL not support parameterized queries? If that's not the case, then what kind of attacks are people using to hack these sites?

Re:I don't get it... (0)

Anonymous Coward | more than 5 years ago | (#26794727)

How is PHP/MySQL so insecure?

It isn't.

Is PHP vulnerable to buffer overflows the way old C code is?

Zend Core, the built-in functions, and extensions are implemented in C. Don't know what you mean by "old"; C has never had and doesn't have bounds checking without libraries. The core of PHP is frequently updated, like anything else.

Does MySQL not support parameterized queries?

I think we might be having a semantic difficulty here, but guessing about what you mean, stored procedures were introduced in 4.1 (five years ago).

If that's not the case, then what kind of attacks are people using to hack these sites?

SQL injection, occasionally assisted by javascript (XSS type attacks). Same as in asp.net world.

The problem is a combination of a couple of factors. The PHP core team couldn't/wouldn't take the old mysql_* functions away from developers (they were built previous to mysql's support of transactions, stored procedures, etc), and the language is so easy to use that many people actually make money by just copypasting scripts.

On the first factor, there was already too much gnashing of teeth about old scripts breaking (and by old I mean a decade) in the community, and woe unto the core devs if they were to resist.

On the second, what can they do? Make the language harder?

It's kind of unfair to pick on PHP... Many "experts", critics and code samples are stuck in the paradigm that php was in back in 1999. PHP has moved on, but unfortunately (or fortunately for some), ancient scripts run fine.

Btw... I'm sure you know this, writing asp.net for a living and all, but it is perfectly possible to write insecure code on your stack, too.

Re:I don't get it... (0)

Anonymous Coward | more than 5 years ago | (#26794785)

A web developer who doesn't use parameterized sql queries is a sql injection attack waiting to happen.

Yes, mysql offers them. Yes, PHP provides them. But only a small fraction of PHP coders use them (or even know of their existence or recognize the term).

Re:I don't get it... (0)

Anonymous Coward | more than 5 years ago | (#26794873)

A web developer who doesn't use parameterized sql queries is a sql injection attack waiting to happen.

Yes.

But only a small fraction of PHP coders use them (or even know of their existence or recognize the term).

I'm not sure where you're going with this. Are you saying that Microsoft stack people are better about this [google.com] ? Sorry if I'm misunderstanding.

Re:I don't get it... (1)

IBBoard (1128019) | more than 5 years ago | (#26794911)

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 general hacks are the normal site exploits caused by people being taught to just use query strings and posted values as-is by beginner's books and then being hit with either SQL injection, command injection (if, for some reason, they do shell calls using variables), remote includes (passing a URL as a value that's include() [php.net] d, which pulls in remote code if allow_url_fopen is enabled), or standard content injection to do things like put scripts on the page via a link when someone realises the values aren't validated.

Two cents. (0)

Anonymous Coward | more than 5 years ago | (#26795119)

Briefly:

1) There is an unfortunate yet statistically significant correlation between 'choosing PHP/MySQL' and 'having no clue what you're doing', for historical reasons; basically, loads of "start your own web site today in ten easy steps!!" tutorials are geared toward PHP/MySQL. Horror stories ensue.

2) MySQL per se is not insecure, it's just a pain to keep running well under non-trivial load. (Thankfully most Web sites only see trivial load.) But that's a problem for the sysadmins, not the developers.

3) PHP is, I'm afraid, something of a mess (the core developers are, I am told, notorious for their habit to mimic features from other languages without understanding fully what they entail), which results in an effect where the path of least resistance from 'nothing' to 'job done' goes through stark lack of architecture and horrible shortcuts that routinely lead to gaping holes.

The latter point, I think, is the real problem with PHP. I vehemently question the notion that languages are 'just a tool', as you will commonly hear: they're also teachers, insofar as they reward certain behaviors and discourage others. If it's more work to use certain practices and the end results looks the same outwardly (if your language has a tendency to sweep issues under the carpet, for instance), then guess what habits you'll end up learning.

Now, it is, of course, possible to write good, secure code in PHP -- see what the guys over at the Symfony project are doing for instance. (Many PHP frameworks -- hell, many frameworks of many languages -- are crap of the sort that commonly follows from cargo cults, but this one is actually pretty good.) It's just more work than in languages where the use of good practices is the path of least resistance.

Re:Two cents. (0)

Anonymous Coward | more than 5 years ago | (#26795251)

PHP is a good language. There, I said it. And the object model in PHP 5, is, dare I say it, pretty. As far as languages specific to the domain of web development, it's great.

You've got the wrong idea in point 3. The original PHP was created when the web was a much more innocent place. You don't have to use the parts of PHP that have been kept around for backward compatibility; in fact, starting with PHP 6, you won't be able to.

I'm glad you concede that it is possible to write good, secure PHP. But I think you're just wrong about the good practices stuff. I'll grant you Java, as they don't have a phobia of frameworks. And Rails, well, is a framework, and there's nothing in Ruby to stop you from doing something stupid.

And as a counterexample to your belief that great languages encourage good practices by making bad practice harder: C.

Suhosin, etc... (5, Informative)

dchamp (89216) | more than 5 years ago | (#26794545)

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:Suhosin, etc... (1)

sapphire wyvern (1153271) | more than 5 years ago | (#26795671)

- 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:Suhosin, etc... (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26795875)

A built in validation class for what input?

Name? Ok, I guess that one might be a possibility. Letters and punctuation, but no numbers, right. That's easy. Oh wait, then there's someone named "Henry the 5th". So basically everything goes.

How about the zip code? Let's write a built in validation class for a zip code. That's always five numbers, right? Not if you don't live in the US. So, it's just numbers, no letters? Too bad for those living in the UK. They have numbers, letters and a even a space.

The comment field... What's valid in a comment field? Letters and numbers? Sure. Punctuation and quotes? Absolutely. ';DROP TABLE STUDENTS --? That too, how else would we be able to discuss SQL injection?

fix the braindead things first (1, Informative)

Anonymous Coward | more than 5 years ago | (#26794575)

SQL injection: Use prepared statements. Always. Period. Do not EVER interpolate or concatenate user input into a query. SQL injection was pretty much solved years ago and it's an embarrassment that sites still fall prey to it. With PHP, this requires mysqli.

Javascript injection/XSS: Find a template language that escapes BY DEFAULT and only prints raw HTML if you explicitly ask for it. You're on your own there; I'm not familiar enough with the PHP ecosystem to name one.

The usual PHP advice is "well, just wrap your input in these three functions every time you use it." That's just begging to forget it a few times, which leads to a few holes you are unlikely to notice. Security should be a default; it should not require constant extra work on your end.

If you cover those two and make sure you keep all your software patched, you will already be well ahead of the curve.

Enforce good passwords (2, Informative)

kabrakan (13409) | more than 5 years ago | (#26794615)

Ensure your users pick good passwords [darkreading.com] , by preventing them from entering passwords described here (e.g. their firstname, "password", "qwerty", etc).

Mmm... Cheese... (1)

UbuntuniX (1126607) | more than 5 years ago | (#26794617)

Anyone else hungry after reading this article?

80-20 rule (3, Informative)

SethJohnson (112166) | more than 5 years ago | (#26794649)



I'm not suggesting this is rock-solid security. It's a few easy steps that keeps most of the knuckleheads at bay.
  • Set up your site on a hosting service with automated backups. Dreamhost has a great backup system that can restore your entire site with DB in minutes once it's been compromised. This will satisfy your client while you figure out how the defacer did his trick. It also puts the burden of OS-level security on them, so any intrusion will be incredibly unlikely to escalate priveleges and purge the logs.
  • Minimize use of web software packages (forums, blogs, photo galleries, etc.). This will limit your site's exposure to known exploits when you fail to keep these packages updated. If you must use such a package, edit the paths so that it won't fall prey to automated script attacks spidering for these packages. This makes upgrades more complex, but it will repel the dumb script kids.
  • Use .htaccess to ban foreign IPs. Most small-time sites have no need to be visited from overseas IPs. The site you build for a dentist doesn't need to be accessible to a kid sitting behind a computer in Brazil.
  • Check your form inputs. Plain and simple.

Seth

Re:80-20 rule (1)

Man Eating Duck (534479) | more than 5 years ago | (#26794941)

Use .htaccess to ban foreign IPs.

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

How is this usually done?

Re:80-20 rule (1)

rHBa (976986) | more than 5 years ago | (#26795829)

The site you build for a dentist doesn't need to be accessible to a kid sitting behind a computer in Brazil.

Don't forget to allow all those poor British IP addresses access though...

idiots (0)

Anonymous Coward | more than 5 years ago | (#26794687)

I have an idea! Let's rename this site to cluelessitadminswhocannotfigureoutshitontheirown.com

Real IT admins do not publicly ask for help, they use the infinite power of the intertubes and find the answers on their own.

Lesson #2 will cover the many reasons why you should not include your real first/last name in your username, for example kdawson. Stay tuned for an exciting preview!

You are well and truly f'd. (1)

mxs (42717) | more than 5 years ago | (#26794717)

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 let's face it, if you did not pay attention to security until now, it will), you better be sure not to be handling any sensitive information (such as ANY personal information of other people, email addresses, payment records, etc.), have very good backups, and have a way to spot whether you have been compromised (contrary to popular opinion, "hackers" don't usually/always deface your website or send you threatening emails or the like; ask yourself whether you would know that somebody is abusing your servers if that did not happen ... But that would also require security-aware programming).

simple, effective starting point (4, Funny)

dltaylor (7510) | more than 5 years ago | (#26794753)

tight security only slows 'em down (2, Insightful)

petes_PoV (912422) | more than 5 years ago | (#26794757)

Have a way to restore the site quickly, reliably and with the minimum of fuss.

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.

Four part guide to secure PHP (0)

Anonymous Coward | more than 5 years ago | (#26794771)

http://www.addedbytes.com/php/writing-secure-php/ is a useful four-part guide to the basics of writing secure PHP. I found it to be a very helpful read.

Just a few principles I try to adhere to (1)

KarelK (942760) | more than 5 years ago | (#26794787)

Just a few things that pop into mind... (a) I second one of the above posters - try to move more content into the "static" section. This should be just a basic design principle of the site. For example: is there content that doesn't refresh more often than each 5 minutes? If so, don't let a PHP page pull it out of MySQL; instead, write a stand-alone PHP or Perl script that accesses the database and pre-cooks an HTML page. I'm often surprised how many sites build dynamic content using a CMS (or ~like) approach while this is totally unnecessary and bad for performance too. (b) On the database access layer: of course stored procedures and prepared SQL statements. (c) In general, when e.g. validating user input, or remote IP addresses, or just about anything: Use whitelists, never blacklists - meaning: have a set of allowed inputs which are accepted, and all else is denied (instead of the other way 'round). Test extensively for e.g. Javascript injection in input fields. (d) On PHP coding: Try to abstract all operations into layers / classes. It will save you tons of headaches later. Never "take a shortcut" in coding, by which I mean that you do the quick 'n' dirty thing because "this code will only be used on this page" or "this code will be here just for testing". Quick 'n' dirty code tends to boomerang back to you. (e) During coding, prepare your regression tests, which are preferably automatically run every time you update the site. Regression tests can e.g. include a fancy PHP class and call its methods, and compare the outcome with what the test expects. Always have regression tests for the "good" outcome (no errors) AND for the error conditions that your class should be able to handle. Here too, never take the quick 'n' dirty approach by postponing the writing of tests until you have more time. (f) Whichever technology you choose, follow the forums or mailing lists about that technology. There will be security-related posts or questions that may apply to your site. (g) Strip data that you don't need. For example: Maybe your site stores your visitor's IP addresses so you can cave trolls. Good practice, but the address will probably be only valid for a week or so. Ergo.. delete IP addresses that are older than a week. In the unfortunate case of a database disclosure there will be simply less exposed data. In a similar vein, try not to store plain text data at all. If your site stores something like the answer to a secret question ("what is your pet's name"), then store a hashed value of the answer instead of the plaintext version. Again, in the case of exposure, there will be less data. (h) Take a look at frameworks that protect from e.g. cross site request forgery. If you don't find anything useful, consider coding your own protection against CSRF (by having a hidden form field in each form with a random value, and by having the same value in the user's session. Upon submission of the form, the two values must match. (i) Other than the above I'm sure that there is a ton of good advice.. It's a bit of a lengthy post but I hope that it provides you with a few valid pointers.

WITHOUT breaking the bank? (2, Funny)

jez9999 (618189) | more than 5 years ago | (#26794843)

The banks are already broken. Too late.

Security frameworks for PHP? (1)

siDDis (961791) | more than 5 years ago | (#26794913)

I know Java has a lot of different security frameworks like JSecurity or AcegiSecurity, but I'm not so sure about PHP.

You can start here (0)

Anonymous Coward | more than 5 years ago | (#26794947)

http://cwe.mitre.org/top25/

Paranoia (1)

obUser (1095169) | more than 5 years ago | (#26795161)

Get your defense budget in balance with the threats. I guess this depends on the kind of content you post to the web. But then again we live in a world where social and bank info is apparently still up for grabs. Why put your money in security if someone else is giving the same info away?

No security experts in Slashdot then? (1)

jotaeleemeese (303437) | more than 5 years ago | (#26795207)

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

petes_PoV (912422) | more than 5 years ago | (#26795595)

Everyone with an opinion is able to wade in and represent it as fact (yes, including this one). The fundemental problem with the whole idea of asking question in a forum is that it's very hard to tell the bullshit from the pearls, as every spotty-faced 13 year-old looks exactly the same as an industry icon (except the real talent is far too busy performing paid-for work to bother posting for free).

Even taking the posts that get voted up is dodgy, as people tend to vote up things they agree with rather than replies which are correct, or relevant, or useful. You'd probably be far better taking this questionj to a specialist website / security forum, than posting on a general site like /.

Oh, and if you do go to a specialist site, be specific about exactly what software, versions, platforms etc. you are using, if you want targeted answers.

No quick fix... (0)

Anonymous Coward | more than 5 years ago | (#26795635)

There is no quick fix for computer security.

It takes time to learn about security issues.
It takes time to practice solving each issue.
It takes practice to fight against poorly written code and poorly managed servers.
It takes diligence to ensure your partners and employees don't screw you too. Multi-authenticated processes are probably the best check where no single person has access to the servers, code, database or data.

It takes something I don't have to convince users, accountants and CEOs that they need to take this effort seriously. A reputation burned can never be regained, just ask Monster.com.

Anyone who claims a firewall solves it is wrong.
Anyone who claims server code solves it is wrong.

True security is inconvenient. The trade off is usability.
A starting point: http://www.isc2.org/ [isc2.org]

Consider wrapping your apps with client certs (0)

Anonymous Coward | more than 5 years ago | (#26795393)

one good and strong way is to wrap your apps with client certificates. if you can reasonably trust your users (to not throw 0day exploits at your site with a client certificate) it's a great way to keep the bots, worms, etc off your code. this gives you a bit more flexibility on time line for upgrading your software down the road at a cheaper cost and more quality testing of said upgrades.

Note, however, client certificates are somewhat foreign to 95% of the internet population. whatever cert. management system you use, would have to be mostly transparent to your users.

Basic precautions (0)

Anonymous Coward | more than 5 years ago | (#26795399)

Some of these have been said, but IMO (and to reiterate):

- Offsite backups = good idea

- If you write your own apps, ensure that you have sufficient validation of ANY code that does or can accept/output user supplied data; don't just limit yourself to forms.

- If you use third party apps, ensure that you keep on top of vendor updates -- this includes OS level patches that could pose a risk to your environment.

- Run a host-based firewall (eg. iptables) on top of any hardware devices you or your provider might have. Only open up what you need; to whom you need, for any given service. If you're overly paranoid, filter outbound traffic also.

- Limit what information you make available about your system/environment to the outside world (ie. no phpinfo() pages, apache set to ServerTokens Prod, etc.)

- Use common sense when administering your environment. (eg. don't use system accounts called 'test' with the password 'P@ssw0rd' when you have SSH/FTP open to the world)

- Encryption is your friend; at rest, or in transport.

- Read as much as you can.

Anonymous Coward (0)

Anonymous Coward | more than 5 years ago | (#26795433)

Most web server attacks are going to be because of a flaw in the site code, not the system code.

Use a framework [wikipedia.org] and you can avoid a lot of the problems with ease.

There is an initial learning curve but it will increase your productivity 10-fold and handle a LOT of the boring stuff transparently.

I recommend Symfony [symfony-project.org] .

XSS, CSRF, and SQL injection (1)

kc8jhs (746030) | more than 5 years ago | (#26795451)

Learn what each of those are, and then study 3 major applications or frameworks to see how they go about preventing them.

For instance, Drupal, Wordpress, Joomla, CakePHP, CodeIgniter, or the Zend Framework.

I'd say you're own your own in regards to privilege escalation and logic errors with your own code.

Static analysis (1)

olehenning (1090423) | more than 5 years ago | (#26795541)

Static analysis tools are quite nice to point out the problems that are present in your existing code. I've used Fortify for Java code and was quite pleased with that. Just remember to be wary of false negatives. You need to review the code manually as well, but automated tools help you get started quickly.

framework (1)

Tom (822) | more than 5 years ago | (#26795579)

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 every time, everywhere. That's when you want a function to handle it, or a framework to shove all the stuff off to.

Learn about security to get good web security (2, Informative)

Bearhouse (1034238) | more than 5 years ago | (#26795639)

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

scovetta (632629) | more than 5 years ago | (#26795849)

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 outsource an assessment on the cheap (really), send me an e-mail [yasca.org] .

Check out the standards (1)

InterStellaArtois (808931) | more than 5 years ago | (#26795985)

If you really want to go to town on security, then look at the standards which have come from research and practice over the years.

For example the PCI DSS is a security standard for payment card industries. Their documents go into detail on the specific vulnerabilities that needs to be addressed to be certified. For example they mention specific flaws (say cross-site scripting), and also measures to protect data if an attack succeeds.

This document [pcisecuritystandards.org] lists specific flaws that are known to be a problem, and had better be comprehensive since these are the standards banks are measured against. "Comprehensive" is perhaps a gross understatement, but it will give you an idea of the aspects to watch out for.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

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

Submission Text Formatting Tips

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

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

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

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

Loading...