2

I have a php site that lets registered users login (with a valid passord) and sets up a session based on their UserID. However I'm pretty sure thisis being hijacked and I've found "new" files on my server I didn't put there. My site cleans all user input for SQL injections and XSS but this keeps happening. Has anyone got any ideas on how to solve this?

Mark Sandman
  • 21
  • 1
  • Clarify what you mean by "new" files? What kind of file, and where? – Frank Farmer Apr 18 '10 at 18:30
  • 2
    It's more likely a vulnerability in your code than session hijacking, but it's impossible to say unless you can provide some more details. – zombat Apr 18 '10 at 18:33
  • I think it's an Iframe malware. – Emily Apr 18 '10 at 18:35
  • Okay, I found a file on my server called searches.php that wasn't written by me and in the browser it showed my database tables, connection strings, everything. I found some images called 7.php.jpg (not mine). I've stopped using session cookies using .htacess. The user logs in and is given a sessionID based on their userID. I use this to identify their settings, details, etc. Can I use session_regenerate_id() to help protect myself. In the meantime I'll look into Iframe malware – Mark Sandman Apr 18 '10 at 18:56
  • 1
    Is there any code in _your_ scripts that obviously (obvious like in "yeah, of course it does") writes data to the filesystem? Is it a root server where you can do more or less anything you want (e.g. installing additional software + patches, setting read/write permissions for files and directories and so on and on)? – VolkerK Apr 18 '10 at 19:11
  • There some code that lets you write to the filesystem.The site is a 1and1 managed business server so I don't have much control over it. But you can do much anything on it – Mark Sandman Apr 18 '10 at 19:26
  • 1
    I don't know if this is a red herring but I get the following in the JS console when viewing my site in Firefox "potentially vulnerable to CVE-2009-3555" – Mark Sandman Apr 18 '10 at 19:31
  • 1
    Can you post up parts of that searches.php and 7.php.jpg? – Pekka Apr 18 '10 at 20:22
  • 1
    Have you been talking to 1&1? It's unlikely, but it could just as well have been a break-in on their end, i.e. on a level that you can't influence at all. Anyway, they may be able to be of some help in finding out how this came about, which is the most important thing right now (apart from taking the server down and/or changing any and all passwords of course.) – Pekka Apr 18 '10 at 20:24
  • You need to post *something* for us to look at. Just telling us what the problem is won't let us help you any better. Consider if I went to a deli and told them that I wanted a sandwich to satisfy my hunger. They'd look at me and say, "That's what we're in the business of," but they know nothing about how to help satisfy my appetite. – mattbasta Apr 19 '10 at 00:40

3 Answers3

2

A session cookie hijacking should NOT allow an attacker to create new files on your server. All it could do is given access to an authenticated user's session. It'd be up to your code, and/or the server's configuration that would allow uploading arbitrary files to the site's webroot.

To check for remote compromise hits, get the file creation times of the suspicious files (searches.php, 7.php.jpg) etc..., then comb through your server's logs to see what was happening around that time. If you're logging the session ID along with the rest of the hit, you could trivially see if the session was hijacked, as it would be used from two or more different IPs during the session's lifetime. It'd be especially obviously if the original user logged in from one ISP, then suddenly appeared to jump to a completely different ISP.

And of course, how are your sessions implemented? Cookies? PHP trans_sid (passing the session in hidden form fields and query strings)? trans_sid is especially vulnerable to hijacking, as the mere act of sharing a link to something your site also transmits the session ID, and any external links on your site will have the session ID show up in the HTTP referer.

Marc B
  • 356,200
  • 43
  • 426
  • 500
1

The solution that PHP experts have come up with is to use unique keys/tokens with each submission of the forms, have a look at the idea here at net-tutes.

Don't forget have a look at the PHP Security Guide.. It covers topics including XSS, Form Spoofing, SQL Injection, session hijacking, session fixation and more.

Remember, always use proper data types in your queries, for example use the int or intval function before numbers and mysql_real_escape_string function for the string values. Example:

$my_num = (int) $_POST['some_number'];
$my_string = mysql_real_escape_string($_POST['some_string']);

You may also use the prepend statements for your queries.

Popular Project To Secure PHP Applications:

Sarfraz
  • 377,238
  • 77
  • 533
  • 578
0

I'll have ago and say that your 'cookie' is easy to guess.

Some sites, when the user logs, just create a cookie and the authentication code just checks for the EXISTENCE of a cookie.

Now, if I register and login to your site and then cut your cookie open and notice that you just store my user id then I can manipulate the value to some other user id and voila!

You get the idea.

zaf
  • 22,776
  • 12
  • 65
  • 95