0

Maybe it's simple question but I would like to discuss it with other specialists.

The problem.
User submits some form (for example post new thread at forum). His browser send data to web application, web application purifies data from js code and saves it to DB. That's ok.

Another case - user submits data to web application but he makes some error in data and the web application returns its data (without saving it to DB), put them in form (in order user not to fulfill all again) and displayes message error.

The question.
I've read somewhere that the following attack can be done - user follow some link (foreign link) that redirects to our site and sends with it data with js. So the question - should we purify data in second case?

  • If you make submitting your form async then you won't need to worry about managing data in the second case. Simply return a request fail and ask the user to recheck the data. Since the user never left the page all the form data is still intact. – Etheryte Feb 02 '15 at 17:07
  • What do you mean by "purify data" ? – MaxZoom Feb 02 '15 at 17:11
  • Need any more help with this? If so I'll update my answer. – SilverlightFox May 09 '15 at 10:42

2 Answers2

0

All you have to do is to submit the form by AJAX.

$("#myForm").ajaxForm({url: 'server.php', type: 'post'})

or

$("#myForm").ajaxSubmit({url: 'server.php', type: 'post'})

If the data was:

  • correct you return the URL to redirect.
  • invalid, you return the errors to display.

No need for additional functionality like "purify data".

MaxZoom
  • 7,619
  • 5
  • 28
  • 44
0

Do you mean a CSRF attack (Cross Site Request Forgery)?

This is where if your site has a form, say it is example.com:

<form method="post" action="/postThread.php">

an attacker could include a similar form on their website:

<form method="post" action="https://example.com/postThread.php">

and entice the victim to visit their site whilst they are also logged into example.com.

They could include some JavaScript to submit their form (either by submitting the HTML form, possibly loaded in an IFrame or by AJAX). The end result is that the thread would be started on your site by the attacker, under the identity of the victim, as the victim's cookies would be submitted with the POST.

A quick way to defend against this is to set and check the X-Requested-With header if all your POSTs are done via AJAX. If not, you may want to look into the OWASP recommended Synchronizer Token Pattern.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145