Be a Supporter!

Common PHP exploits?

  • 1,831 Views
  • 10 Replies
New Topic Respond to this Topic
atomic-noodle
atomic-noodle
  • Member since: May. 17, 2005
  • Offline.
Forum Stats
Member
Level 14
Blank Slate
Common PHP exploits? 2008-07-02 06:22:51 Reply

I'm about to re-release a site but I am terrified of getting hacked. So, can anyone tell me what are some common ways of hacking user systems? I've added security functions such as stripslashes, strip_tags, and mysql_real_escape_string. But I'm not the best with security. Any post with examples on how i can test for the exploit would be great :)


iamcoreyg.com // campnorth
Need a website? music? graphics? CONTACT ME.

BBS Signature
notsquid
notsquid
  • Member since: Jun. 24, 2008
  • Offline.
Forum Stats
Member
Level 02
Blank Slate
Response to Common PHP exploits? 2008-07-02 06:28:51 Reply

Is every user entered variable checked? Is every variable that's going near a database mysql_real_escape_string'ed?

BoneIdol
BoneIdol
  • Member since: Aug. 14, 2006
  • Offline.
Forum Stats
Member
Level 05
Blank Slate
Response to Common PHP exploits? 2008-07-02 07:08:29 Reply

First and foremost, XSS (Cross-site scripting).

Basically some scallywag injects HTML and Javascript into your user input. If this is stored some way, such as in a database, this is called persistent XSS and is very, very bad. For example I could enter:

<script type="text/javascript">
alert('Buy cheap viagra!');
</script>

You should watch out for none-persistent XSS too; I can inject code into a get variable and send it to someone and use your site to hack them by proxy.

XSS can usually be solved by a few well placed htmlentities().

Second big problem - SQL injection. User inputs a string like..

" AND A=B; --

..into your login box to bypass your password check. Or, if they want to be destructive...

"; DROP TABLE users; --

As you can see, this is quite bad. Solution is simple: wrap any user input used in a query with mysql_escape_string. Remember that even uploaded file names can be used to inject sql strings with minimum difficulty. I think it goes without saying not to pass SQL statements via user input.

Another hack to watch out for; using user input for filenames/urls/filepaths etc. If you were to say, fopen() a textfile via get variable with a url like:

page.php?file=files/text_file.txt

Someone could feed it..

page.php?file=../includes/database.php

...to get your database password. Seriously, do not mix user input with fopen, include, file_get_contents or even imagejpeg. People still make this mistake.

While we're on the subject, file uploads count here so use basename(). In theory I could upload a file called ..%2Findex.php to overwrite your index page. %2F is a url entitiy for /, which isn't allowed in filenames.

It is also possible to steal peoples' cookies, and therefore their sessions, so make sure that cookies expire within a reasonable time frame. Otherwise you may have someone logged into your control panel that you really don't want there.

Basically user input is the devil and should be treated like the source of a bomb scare. Backslash-escape, typecast and generally validate to hell.


Sufficiently advanced incompetence is indistinguishable from malice.

elbekko
elbekko
  • Member since: Jul. 23, 2004
  • Offline.
Forum Stats
Member
Level 16
Blank Slate
Response to Common PHP exploits? 2008-07-02 07:09:21 Reply

1) You shouldn't need stripslashes(), except perhaps to override magic_quotes_gpc. If you do, you're probably doing something wrong.
2) All input must be sanitised. Use mysql_real_escape_string() for text, use round(), intval() or floatval() (depends on the size and type of the numbers you're expecting) for numerical data. You could also use parametrised queries.
3) Don't use strip_tags(). It's a godawful function, and will also strip stuff like '<< IMPORTANT >>'. Preferably run htmlspecialchars() or htmlentities() when outputting the data.
4) Don't blindly trust anything the user can modify. This includes referrers, form data, uploads, mime-types, ... Preferably use PHP's built-in functions to double-check these (form data has already been mentioned in 2)).
5) Don't rely on or even turn on register_globals. If it's turned on, make sure you *always* initialise variables. I suggest setting error_reporting to E_STRICT for this.

If you follow those basic rules, you should be pretty much fine.


"My software never has bugs. It just develops random features. " - Unknown

[ FluxBB developer | Quickmarks 0.5.1 | Strings & Ints - my blog ]

BBS Signature
henke37
henke37
  • Member since: Sep. 10, 2004
  • Offline.
Forum Stats
Member
Level 30
Blank Slate
Response to Common PHP exploits? 2008-07-02 07:29:28 Reply

I would point at my signature, but my server is down for a while (I should probably change the signature).
But I can recommend one concept, tainting. There is some tainting extensions to php out there that will make it very very obvious when you mix up two unrelated string encodings.


Each time someone abuses hittest, God kills a kitten. Please, learn real collision testing.

atomic-noodle
atomic-noodle
  • Member since: May. 17, 2005
  • Offline.
Forum Stats
Member
Level 14
Blank Slate
Response to Common PHP exploits? 2008-07-02 14:32:02 Reply

Ah, thanks. Much more info than i expected. :)


iamcoreyg.com // campnorth
Need a website? music? graphics? CONTACT ME.

BBS Signature
BoneIdol
BoneIdol
  • Member since: Aug. 14, 2006
  • Offline.
Forum Stats
Member
Level 05
Blank Slate
Response to Common PHP exploits? 2008-07-02 15:02:49 Reply

An obvious one that I, and everyone else, have overlooked is validating filetypes in uploads. If you don't validate the filetype someone could upload a php file that does something like output file_get_contents on your scripts.

Make very sure to validate by file extension rather than mime type; I could very easily upload a .php file that will give an image/jpeg mime type both in the $_files superglobal (which is supplied by the web browser) and when the file is passed to some form of mime function and still make it contain php code.

Naturally, you need to be careful when writing user input to file as well; especially if the filetype is .html, .php, .asp or something similar. You need to be very careful with if you do cache to these file types as well. Also, make very sure not to include cache files, as any php code passed to include is executed regardless of whether the filetype is .php or not.

I think I may have been thinking about how to break websites more than is healthy...


Sufficiently advanced incompetence is indistinguishable from malice.

Will
Will
  • Member since: Mar. 18, 2006
  • Offline.
Forum Stats
Member
Level 11
Blank Slate
Response to Common PHP exploits? 2008-07-02 15:09:35 Reply

Get some people to try to hack it to find exploits before you put it online, i'm sure some people here would be willing.


BBS Signature
Seachmall
Seachmall
  • Member since: Jul. 22, 2006
  • Offline.
Forum Stats
Member
Level 07
Blank Slate
Response to Common PHP exploits? 2008-07-02 16:16:30 Reply

At 7/2/08 07:29 AM, henke37 wrote: I would point at my signature, but my server is down for a while (I should probably change the signature).
But I can recommend one concept, tainting. There is some tainting extensions to php out there that will make it very very obvious when you mix up two unrelated string encodings.

I've clicked that link numerous times trying to get that article, is there any chance you could upload it to another site while yours is down? PHP:Main or Coder Profile (check my sig) for example? Security is something I tend to get a bit paranoid about so I'm looking for some decent articles ;-)

elbekko
elbekko
  • Member since: Jul. 23, 2004
  • Offline.
Forum Stats
Member
Level 16
Blank Slate
Response to Common PHP exploits? 2008-07-02 16:23:41 Reply

I've actually mentioned that in my post BoneIdol, although not in that many words ;)


"My software never has bugs. It just develops random features. " - Unknown

[ FluxBB developer | Quickmarks 0.5.1 | Strings & Ints - my blog ]

BBS Signature
BoneIdol
BoneIdol
  • Member since: Aug. 14, 2006
  • Offline.
Forum Stats
Member
Level 05
Blank Slate
Response to Common PHP exploits? 2008-07-02 18:40:52 Reply

At 7/2/08 04:23 PM, elbekko wrote: I've actually mentioned that in my post BoneIdol, although not in that many words ;)

I see that now, carefully tucked away in that list. Feel it does need elaborating on a bit though; a lot of people seem to forget that file uploads are actually user input. They are pretty much the most input a user can give, admittedly, but people still seems to think they're a special case.

A lot of the work I do is maintaining code other people have written and I never see any validation on file uploads beyond "has it uploaded or not?". Which is fine for things like private control panels for a small website, but not exactly good when the great unwashed gets involved.


Sufficiently advanced incompetence is indistinguishable from malice.