Hacking a SQL table via a php textArea message

This site is best viewed in a modern browser with JavaScript enabled.

Hacking a SQL table via a php textArea message

robkir

How do I stop an attacker from maliciously updating one of my database tables (Hacked by Mr.Henk404)? I don't see any indication they hacked my username/password yet they were able to access a table and change the textArea display message.

If the password protected administration page(s) aren't accessible, how do the hacker's get in?

Weedpacket

You've given us nothing to go on. You could have hundreds of vulnerabilities in your code or configuration. You could have a look at This Top Ten list and see if any of them look familiar.

NogDog

Yeah, could be any of many different things, though the first that came to my mind was SQL injection. How do you sanitize any submitted data before using it in a DB query? Prepared statements with bound parameters? Applicable escape functions (correctly and rigorously used)? None of the above?

robkir

The user does not input any info. The text is entered by the site manager. Can a hacker perform an SQL on a textArea display message.

The display code is straightforward (or, at least, I think it is).

$query ="SELECT workshopMsg, workshopTimes from vq_info Limit 1";
$result = mysqli_query($cxn, $query) or die ("Unable to connect") ;
$row = mysqli_fetch_assoc($result);

echo "<textArea disabled='disabled' rows='18' cols='100'>".htmlspecialchars($row['workshopMsg'])."</textarea><br /><br />";

Thanks for helping me with this.

Weedpacket

Why is it a textarea if the user isn't supposed to put any information in it? It could just be a paragraph of text.

It's a matter of what the server does with submitted forms. The textarea is marked as "disabled", so that it would not be included in a form submission, but there's nothing to stop the user ignoring or removing that attribute. If there is a form involved here then defying the disabled attribute will mean the textarea gets included as part of the form submission.

Any form field can be attempted as part of a SQL Injection attack - even fields that don't exist in the form at all. The server doesn't care about "form fields" or different types of them.

NogDog

No, it would not be vulnerable simply because it's in a text area. SQL injection would occur any place you do a DB query where any part of the SQL contains data from anything external: URL query string (GET) parameters, form (GET or POST) field values, cookies (easily faked), and so forth. That specific query you showed does not use any such values.

Weedpacket

NogDog
Right; choosing the text to display in a textarea initself isn't the vulnerability. The given query just picks a random one of the already-existing entries in the vq_info table for display and then the rest of the code displays it.

What's far more interesting is what happens after that - and it's probably something to do with the fact that the OP feels the need to put the text in a form field.

(Or of course it might be something completely other: if anyone is still using shared hosting they're vulnerable to attack via any vulnerabilities on other sites on the same host.)

robkir

What would you recommend to hunt down the most likely vulnerability?

I changed the text area to a paragraph. Maybe that will help.

Weedpacket

robkir I changed the text area to a paragraph. Maybe that will help.

If you could do that without problem (i.e., you were never submitting the content of that textarea) then it won't help. It just means it was never the vulnerability.

dalecosp

Read your logfiles. Starting with the ones where the client used POST, but if you use GET strings much, you'll have to do those as well.

robkir

dalecosp Hi dalecosp,

I am not familiar with logfiles. Where would I look for it?

I appreciate any help you can give. Thanks.

robkir

dalecosp

Without knowing your system, I can't say. For Apache, the directives ErrorLog and CustomLog should have a value that would be equal to the location of the log files. These are typically found in server configuration files such as httpd.conf, but could be in any files that may contain a <VirtualHost> container (included files, etc.).

If you use the nginx server, these correspond to the directives error_log and access_log in nginx.conf.

If you're using a Windows server, I don't really know, but "Computer Management" might get you started.

robkir

Thanks dalecosp. I hate to admit it, but SQL and Apache are a bit beyond me--other than creating tables, etc. If worse comes to worse, I could put the administrator's message directly into the code and eliminate the weakness altogether. It only updates once a month (still... that's a pain).

dalecosp

If you can't access the log files, you're in need of someone who can. Ask the admin, your supervisor, or the staff at your hosting company for help. The ability to alter your DB tables via an unknown/external security hole should be a legitimate and rather serious concern to anyone with good sense who works for your company or the company you use to host your projects/servers.

robkir

I located the log files and discovered that my hosting company rotates them out every week ---its been three weeks since the last hack attack. If another attack occurs, I'll immediately check the logs.

At this stage, I guess I'll just have to wait to see if I get another attack. I also changed the form field's name just in case the perpetrators were able to deduce it.

robkir