Jump to content

Recommended Posts

Posted

Ahoy.

 

Well. I've had the unfortunate experience the other day; some idiot kid tried to add himself to my skype contacts. When I (quite politely, I must add.. he's an ass) refused, he stated he is going to hack into my website.

 

I'm a PHP/mySQL programmer, so I know a thing or two about servers. I wasn't all *that* worried about the actual code (server access is not really something he could acquire, at least not in his very low level, as I was convinced he has later on). But I figured I probably *should* do some reading and improve my security.

 

My website is just an example of what I can do in PHP/mySQL for potential customers or just people who want me to program something for them, so most of the modules are harmless to the site (I have 2 "modes" -- realsite and 'playmode'. Playmode is harmless, goes to a completely different table and not affecting the actual website).

 

But still, it's communicating with the database.

 

Reading a bit about SQL injection, I added some measures of security. I made these major steps in a generic function for all inputs. The function, generally, does this:

 

1. adds slashes (addslashes() function) just for extra measure to avoid " or ' in the injection.

2. Replaces < with < and > with &gt just in case.

3. uses the generic php function --> mysql_real_escape_string() with the input text

 

 

I also added a CAPTCHA script.

 

I only have 3 potentially "hazardous" scripts in my site: guestbook.php (not really supposed to hold info, I'm deleting it periodically, it's just an example of a very simple one), News Module, and Registration.

 

So far the idiot has went into my guestbook.php page and inserted auto-load links (javascript and <a hrefs>) so when I visited my own guestbook.php it refered me to microsoft.com. I fixed that with the security measures above, which caused his attacks to just APPEAR in the text (instead of being actual links, they just showed <a href> in the comment box, which is quite harmless).

 

I must say - I tried to build a regex to recognize javascript/a href fields in the guestbook comment input, but something wasn't right -- the script kept telling me the regex was bad (I tested it in a regex-simulator, and it was fine.. so.. weird).

 

So. Here's my request for help:

 

I am not very well versed in total security, so whatever knowledge i have right now came from my limited google search and studying SQL injection.

 

Anyone has any suggestions? Anyone knows what other attacks on the db I should anticipate for?

 

I created a dummy table called " tDummyUsers " to experiment on; So far 2 people tried to drop it, but failed.

 

Anyhoo, my site is here: http://moriel.schottlender.net/ The guestbook and news module is under "Modules" (under PHP Programming).

 

(EDIT: I will also paste the REGEX string with the code I tried to recognize with, right now I can't find it and I need to get off to school soon... it didn't work, though, so suggestions about *that* would be great too.)

 

Suggestions would be appreciated.

 

~moo

Posted

There are standard php functions to strip html tags, and to convert all characters into thei & form, these should ALWAYS be applied to anywhere where I user can add text. As well as the above mentioned addslashes (although this can be forced on all entered text in the php.ini, so a generic function has to check if it's set and then decide whether to addslashes).

Posted

For input, you only need to do mysql_real_escape_string(). Don't addslashes() and that, as mysql_real_escape_string() does what addslashes does and more.

 

For output, you'll want to parse the output with htmlspecialchars() before you display it. That will prevent typical cross-site scripting and that fun stuff. You don't need to worry about using a regex to find JS with that because the JS tag will be shown, rather than parsed by the browser.

Posted
For input, you only need to do mysql_real_escape_string(). Don't addslashes() and that, as mysql_real_escape_string() does what addslashes does and more.

 

For output, you'll want to parse the output with htmlspecialchars() before you display it. That will prevent typical cross-site scripting and that fun stuff. You don't need to worry about using a regex to find JS with that because the JS tag will be shown, rather than parsed by the browser.

 

These are good for cross-site scripting.. what about SQL injection? Or.. maybe another method I am not aware of? I only learned that SQL injection exists because that of that guy.. I'm hoping to learn *before* him.

 

So --- uhm --- what other hacks should I worry about?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.