Page 1 of 1

Discussion of Ajax safety

Posted: Mon Aug 24, 2009 5:40 am
by morris520
Hi guys

recently found an issue on Ajax while I was doing my project. The way I did it is:
from pageA I set a div up so later I can use Ajax to load data into it. Then when user start keying I use Javascript event 'onkeyup' to trigger the Ajax (second page called pageB.js where the Ajax engine is). The ajax page will call another pageC which has stuff like SQL queries to load data from database.

In this framework, which my company insists to use quite a lot, I found the pageC is not so safe at all. If someone access pageC with his own query_string, he can explode the database.... I guess

So I come to ask for your opinions how i cans protect pageC and avoid the damage as much as possbible? I am quite new to PHP just found this issue when my compnay was doing a PCI scan for the site. The scan result says pageC is vunulable to attack.

Thanks for any replies.

Morris

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 6:04 am
by jackpf
The ajax shouldn't make a difference...

Are you escaping data properly? As in, using the database escape functions, such as mysql_real_escape_string()?

In what way is it vulnerable? SQL injection?

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 6:06 am
by papa
I agree with Jack.

Make sure you validate the input.

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 12:00 pm
by Darhazer
AJAX should not differ from any user input. If you have vulnerabilities in code, that uses AJAX, that you just have general vulnerabilities.
For the data, it should use the same Model as the page itself...

Anyway, all of this is just theory... I find that many people trust what have been posted via AJAX just because they have entered this into a .js file and it is not an "input" from user... but as all we know, the ajax request can be altered even if it does not contain any data that comes from a form.

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 4:40 pm
by morris520
first of all thanks for reply

the problem sits at PageC, where the .js file calls php page as a output to the div, it is a problem with query string, like:
pageC.php?javascript:alert('I can attack here'); (how the scan fails)

Does this make sense? not sure htaccess would help?

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 4:42 pm
by Darhazer
You have to fix the pageC.php, .htaccess is irrelevant in this case.

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 6:05 pm
by jackpf
Hmm....I don't see how that alone is a security threat.

Are you displaying the query string on the page somewhere?

If so, just run htmlentities() or something similar on it...that should sort out most problems.

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 6:06 pm
by Eran
just run htmlentities() or something similar on it
please, not htmlentities. run database-specific escape functions, such as mysql_real_escape_string()

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 6:44 pm
by jackpf
Uhh...that won't prevent the javascript XSS he referred to.

I was under the impression that this was being displayed, not being inserted into the database. If that's not the case, then yes...do as pytrin commands 8O

:P

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 6:51 pm
by Eran
this
pageC.php?javascript:alert('I can attack here');
is not a threat. What's the point of sending this parameter to a server side script? it will not execute javascript. The way I understood it, the results are used for autocomplete, so this is a data retrieval query, not an insertion query. Besides, if it's the current user's input, the only thing he can do is attack himself in this fashion

Re: Discussion of Ajax safety

Posted: Mon Aug 24, 2009 6:55 pm
by jackpf
Oh yeah, how stupid of me :oops:

Then yes, by all means, you need to escape the data with database specific functions.

Even SELECT queries need user suplied data escaping...not just INSERTs and UPDATEs...

Re: Discussion of Ajax safety

Posted: Sun Aug 30, 2009 2:37 am
by kaisellgren
Escape, validate and encode like you always do. The fact that the data goes through an AJAX engine does not make much difference really. PageC should validate all user-supplied data, escape it and encode the output.