Someone has hacked my database - how?

不想你离开。 提交于 2019-11-29 20:21:40
ajreal

mysql_real_escape_string

The MySQL connection. If the link identifier is not specified, the last link opened by mysql_connect() is assumed. If no such link is found, it will try to create one as if mysql_connect() was called with no arguments. If no connection is found or established, an E_WARNING level error is generated.

As explain here : Does mysql_real_escape_string() FULLY protect against SQL injection?

Based on your code snippet, you have connected database twice.

$db_con=mysql_connect($db_host,$username,$password);    

$connection_string=mysql_select_db($db_name);
mysql_connect($db_host,$username,$password);    
mysql_set_charset('utf8',$db_con); 

And you did not supply the database link identifier for :

$email= mysql_real_escape_string($_POST['email']);
$name= mysql_real_escape_string($_POST['name']);
$sex= mysql_real_escape_string($_POST['sex']); 

Therefore, mysql_set_charset has no effect to real escape supplied$_POST for multi-bytes characters.

Suggestion

  • remove the second mysql_connect($db_host,$username,$password);
  • explicitly add $db_con when doing mysql_real_escape_string

It doesn't look like the code you pasted provides a suitable attack. The way I would investigate this is scan the MySQL binary logs for the relevant DROP TABLE statement, to give me a timestamp. Then you can use that timestamp to look for Apache requests you can correlate with it.

Then it's just a case of carefully auditing the code in each candidate request until you nail it :(

Maybe you have a MySQL user with a weak password. I would change all passwords and check who is authorized to connect to the MySQL database. Lock down your firewall so that only needed ports are opened (80,443?)

Here is some articles about locking down your php code http://www.addedbytes.com/writing-secure-php/

Best regards. Asbjørn Morell

The fact your database has been compromised doesn't mean there was a sql injection. If you want, you can share the access log, which should provide enough clues as where the attacker got in. My guess would be local file inclusion, where he included the config file, or perhaps some kind of code execution vulnerability. Without more information it is just guessing though, it may as well have been good social engineering job, or phishing attack...

On the face of it, you haven't left any openings for an sql injection attack. Is this code excerpt definitely the one where the intrusion is taking place?

The only thing I can turn up is this ambiguous announcement from a hosting provider about ucwords: http://2by2host.com/articles/php-errors-faq/disabled_ucwords/

G

I think this is done via php shell ( backdoor). Is that a sharing host? if so, check if other website on the same server are attacked too or not, this will help you to see if the attacker is getting into your site from your neighborhood. To see websites on your server you need reverse ip scan.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!