Topic awaiting preservation: php/mysql security - what to look out for (Page 1 of 1)

so, i pretty much finished the functionality of a mid-sized community portal. now what remains is to have it check for security issues. it uses a lot of forms which will be GET'd or POST'd and fill the database.

i already know about SQL injections but what else is there i should look for?

Cool question.
I'll try to answer in terms of "general software design". It is advice, so, take or leave.

"any" kind of injection is your enemy. You should design in terms of "deffensive programming".
Eg. You should not rely on your users behaving and inputting predictable things. They won't.

* Any input point in such a web application, constantly exposed, is likely to welcome an attack. One that corresponds to a known flaw... or not at all.
This means: avoid direct "contact" between the server side and the interface/client side.

* The classics: include($data) can be exploited easilly to include stuff you didn't expect, it gives the general tone.
I, for one, would double filter all variables that come from the user before using them for something meaningful.

* Sessions.... sessions should only pass an identifier back and forth, that's handled transparently in php, but they should also have a reasonable timeout.
All sensitive transactions should be https-ecured: it's easy to monitor the traffic to a website and back, so no password box without https encryption.

----
Once all the input is triple filtered, never comes to directly influence the server side, and all the sensitive input is encrypted, you're pretty safe on the php side.
Oh, I said all authentifications should be encrypted: never leave a file with the database password available to the end user, put it in a place where it's not on the www.
ALL files containing passwords should be in such a location: available to the php, not to the www.

Watch for custom file formats and associations: custom file types should be processed the right way by the server, and you should avoid these files being readable
from the client side at all costs. For example, if you have .ini files like I do, make sure they can't be read as text on the client side.
----

Other than that, watch for, and google for, "<your web server name> exploit".
Protocols have flaws.
Web servers have to deal with those.

It makes for vulnerabilities, so your web server itself should be well protected.
Eg. it should expose almost nothing about it's configuration: web server admins should be the only ones allowed to know how it is configured.

Watch for a thread by me called "google hacks" for this advice to make even more sense.

wow,

I had no idea about sql injections, that wikipedia link was a good link. Does anyone else have any links about server-side security, more specifically, php and mysql? I would really like to know more.

Thanks

This patient is ready for his medication!

It's easy to find such docs when you know what you are looking for, hence my novel-sized post above

In 2004, we had a nice phpBB exploit: http://news.netcraft.com/archives/2004/12/18/php_exploit_enables_theft_of_phpbb_passwords.html
It's origin were design flaws in php 4/5: http://www.hardened-php.net/index.42.html

Affecting other software like invision board, and leading to "anything a hacker would want to do".
This means you had to consider not only the shortcomings of your own code, but the software flaws of php, http, the web server in use, the os in use, and your sysadmin's configuration
of the server/os to prevent issues.

Another example from 2004, a mysql flaw: http://www.securiteam.com/exploits/6G00P1PC0U.html

Stop for a second and think... how many web hosts are up-to-date regarding security? How many uninvestigated flaws
exist in a homebrewed web-server?

Here is a phpbb exploit from 2005: http://www.filipdewaard.com/archives/38-phpBB-exploit-in-the-wild.html
http://blog.php-security.org/archives/26-phpBB-exploit-in-the-wild.html

And the code is given as well

------------------------------------------------------------

Security is a complex topic. It just doesn't boil down to script-kidding.
To sum up another novel-sized post:

Nobody is perfect.
No system is perfect.
There ALWAYS is a flaw.
Software systems are as onions, they are made of layers.
All places where two layers communicate are subject to security risks.

-------------------------------------------------------------

I recently (like 2 days ago) got to discover a windows security issue. Not a new one, but I "saw it" with my eyes, and it was obvious.
I had an experiment going on about passing "system messages" from an application to another.

System messages represent any event in an OS like Windows. "key has been pressed, mouse button has been raised, combo box has been selected",
and also actions: "enable this combo box".

And these messages are processed regardless of the originator.

Although application endorse security roles (Local System for example, they belong to a "role" with given privileges, sometimes above an admin's privileges).

So? Given the required knowledge, find yourself an application which has a text control (search box for instance, an antivirus software will do),
send messages to this application (you just need run privileges on one executable file), telling it to activate the search box,
paste binary stuff of your choice (malicious code) in that text box, and you're ready to have this application inject your code in the system.

Using it's privileges which are way above yours.

And giving you the full control of the computer in use.

...Another, different example of code injection, but the concept is the same. The two apps are two "onion layers",
and the lack of authentication when they communicate through system messages makes for large gaps between layers.


Wherever you find such a gap, you can jump in right away if you know how.
google whichever software you want to know about and add "exploit" to your query, you'll find more and more links.

Good stuff =)
Thanks for all the info/tips _mauro. Always good to make sure you are looking at the subject from the right perspective.

I would also be interested, however, if anyone does have good resources that are specific to php/mysql, as I am always trying to clean up and tighten up my code.
The problem with google, for me, is that the return is so large, and so many of the results are either not quite relevant, or simply not very good, and I get lost in the ass-load of pages to try sorting through.

I would be very grateful to anyone who can offer either direct tips or links that have direct tips for php/mysql.

I have and will continue to use the resources available at both php.net and mysql.com - they are exceptionally helpful - but necessarily vague on implementation in many cases.

Always (too much) of a pleasure. Let's make it simple and concise.
O'Reilly, 2 simple articles with sample code:
http://www.onlamp.com/pub/a/php/2003/07/31/php_foundations.html

Typical security mistakes to avoid in php:
http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/

A detailed, step-by-step php security guide:
http://phpsec.org/projects/guide/

3rd part of an article series (could not find the other ones) about mysql:
http://www.linuxsecurity.com/content/view/117331/99999999/

All simple, with source code.

Basically, all this echoes what I've said above about onions.
You should ask yourself: "where does my php app end, and where does input from other actors come in?".
Other actors include a mysql server, and the end user in most cases.

That's about it as far as I am concerned, I'd be more than interested to see more php/mysql specific links.
(and why not perl, python, jsp for that matter).



(Edited by _Mauro on 03-01-2006 22:00)

This is a really interesting subject that I definately have to dig deeper into. As for now all I use for mask on the login variables is a function to truncate everything more than the single word allowed. Shouldn't this be enough for a small scale community?

It all depends on your needs. If it is a small community as in "free host, no https", then you are likely to be a target to beginning hackers who want to practice.
Passwords will be a child's play to capture, and over-excited script kiddies will love that.
Statistically, you'll get your site defaced once or twice within a few years. Does it matter to you?

And you have to rely on your web host to track back potential hackers or secure his server in case of issues.

Tell me more about the host and I'll be able to tell you the correct way to balance your security.

Hey does this forum support 'sticky' threads? I would love to see some threads on important topic's such as this being stickied

Excellent - thanks again mauro.

Hiro - that's the role we use the FAQ for. Anyone can start a FAQ entry - add a general subject title and throw a link to this thread in.

You're welcome, glad I could help.
But I am such a lazy bum I won't bother faqqin'it for the time being: enough code is enough code, time to party!

It would deserve a record in the archives or faq though, and some further "updates" as needs arise, so faq sounds right.
Sometime, maybe, when I am not in a "run away from comp" kind of mood....

This is interesting indeed.
We've just had a runthrough on several different ways that a website can be vunerable to attacks, from XSS (Cross Site Scripting), session fixation (Good example here) http://www.acrossecurity.com/papers/session_fixation.pdf , Session hijacking, misuse of include($_GET['page']), _FILE_ and a lot more. I'll see if I can dig up some more detail on it. In the meantime, this is a start: http://www.securityfocus.com/

Basically _Mauro is entirely correct on the fact that vunerability is like an onion, from the web interface, to user input, to servers, to databases, to what you store etc.
Security does not magically popup in one of these layers, you don't even have full control over all the layers.

The ideal situation is basically not to accept any user related input at all, not through querystrings in urls, forms, anything. That won't make you secure but it will remove a lot of your applications holes. If you need user input , treat it like the plauge and do not allow it unfiltered in any way shape or form into your application.

Basically research as if you are a hacker...
You will be surprised and scared on how many ways there are to grab a users account and do stuff... I know I was.

An interesting example is if you accept fileuploads and use PHP's function to check the filetype, then you move the temp file to a new location and try to make a thumbnail of it. If the evil one has created a textfile that fools PHP that it is a jpg but in reality contains an evil script of some sort (this part os frightingly simple) it will be uploaded, moved but naturally not turned into a thumbnail since it's not a valid img. However, the original file will remain in the place it was moved to, all the evil one needs to do is to figure out how to surf to the uploaded file and whatever code in it will be executed, on the server, with the servers rights...
Nice?

/Dan

{cell 260} {Blog}
-{"Theories without facts are just religions...?}-

(Edited by DmS on 03-02-2006 21:05)

Actually, just as the notions of objects and networks, security is a concept that goes way beyond the single user and his pc.
Security in informatics is just a subset of security in real life, I mean all security systems, immune defenses as well as car securities, anything security.

One of the fundamentals is:

Nothing and nobody is perfect.
Therefore..
There always is a flaw.

...Searching the faqwiki about security results in
Faqwiki search for Ozone Asylum : security

So we do have a faq, apparently maintained by Emperor, on the topic:
http://www.ozoneasylum.com/5328

And I've added this thread to the faq. Ta-daam!

thank you all for the info!

I'm experimenting now with my closed community with "pushing" instead of "selecting" when a user tries to login.
Since all members are close friends and not "computer people" I am quite confident that none of them have any evil intentions, but just as a precausion the community is not accessible (a very relative word in this case) unless there is a session with your name on it. And the only way to get one is to login....(also relative)
So, through sessionchecking anyone who tries to access a "suburl" to the site is redirected to the login site, where the standard two input fields are located.
After input, and instead of just running a regular "SELECT * FROM users WHERE login = '$login'" with password check and everything else, I cut that "onion-layer connection" and chose another route.

Before doing a check I SELECT ("push") all the login and password data from the database (don't sweat, there's only like 50 members) and into an array. Then with a simple in_array I check to see if the login and password match.
This, in my eyes, is a simple way to disable any malicious attempts to hack through the login-site, since this is the only input-site accessible to the public.


Please come with feedback on this.

Edit: How accurate is in_array btw?
What is a user enteres for example just an "a" as login and "a" as password? I have to do research on this...



(Edited by justin on 03-08-2006 09:32)

Hi there. Um, I need some help on the PHP security front, as I am currently getting slammed with spam even though I have (or at least I thought I had) measures in place to prevent this. Obviously, these measures are not working. It's a bit of a complex issue (or maybe I just don't understand it), but if anyone would like to help me out, I would be greatly obliged.

InI, I tried to send you an email through the Asylum, but I guess you didn't get it. If you'd be willing to take a quick look at my code, drop by [url\http://www.liminality.org/contact/]my contact page[/url] and drop me a line. Anyone else who feels that they have a solid handle on the issue is welcome too. The issue, in short, is that I am suffering from email header injection attacks in my PHP contact form. At least, I think that's what's happening.

Or, if you'd rather, I can strip the code and spam mails of any identifying information (on my part) and post them here, but this would probably be easier to work out mano a mano.


___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

Hi people, was off for a few days.
Justin, well done on spotting some onion layers inside the php code, this
sounds secure as is to me, BUT....

On the http level, it's a whole different story.
Anybody can sniff packets to your site and capture passwords in plain text,
so anybody (not only the users in your community) can get your admin pass if there is any.

Suho, my contact details are: brundle[twenty-one]at[hotmail.com]
It also is my msn.

I'd like to adress this in another thread, more specific, like "email headers injection". Please send me the code for the sake of discretion.

Thanks InI (er... _Mauro... sorry, old habits die hard ). I'll send the relevant code and two examples of the type of spam I'm getting.


___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

'lo. Just a note to let you know I had lost my HD last week (there's a post named "Ouch" about it in the Ozone)
and, last weekend, lost my cable modem as well (it dropped dead).
I've got my hands on a new cable modem today, will reinstall it tonight, and will then probably waste - hours - reinstalling my missing applications :/ So my activity around this place will be slowed down for a couple more days (including browsing through the hundred pending mails/spams I pro'lly have).

I'll get back to you as soon as possible, Master Suho (I code better without shock therapy, so please be patient, stop looking at that machine like th.. No, wait, NO, I PROMISE, I'll Fix it...)

That's cool, _Mauro. I'll save the shock therapy for when you're finished.


___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup