Several sources, for example this, state that Ajax applications are more complex due to their asynchronous nature, or that Ajax might cause more entry points for attackers, whileother sources claim the opposite. However, the classes of attacks stay largely the same,so the advices given herein apply to Ajax applications, as well, especially input and output validation.
But there is one exception, output validation, as described in the User Agent Injection, cannot be done solely in Rails' view anymore. In a situation where the attacker sends malicious input through an Ajax function and the server does not filter it and returnsa string and not a Rails view, the input will be displayed without validation. For example, Rails provides a function called in_place_editor() which makes string elements on a website editable and sends the new string to the server to save it and return the string again. If this string contains an injection, it will be injected in the result.
The solution is to, at first, determine which data format the Ajax result will be returned in. In Rails applications it is quite common to return plain text or HTML code, but itcould be other formats, such as XML or JSON (JavaScript Object Notation, a lightweight data-interchange format).
In addition to input validation, the user input has to be filtereda ccording to that data format, as well. And it is important to keep in mind that an attacker can bypass client-side validation, use it for performance reasons only, but not as a replacement for server-side validation.
Secondly, you have to move the output validation for Ajax actions that do not render a view from Rails' view to the controller. The h() function works in a Rails controller, as well, and the input validation framework described before (see https://rorsecurity.info/files/transforms.rb) has a data type "htmlescape" which performs output validation, for example:
name = parseparam( params[:name], "empty", "htmlescape")
However, before you perform any action for an Ajax call, you should check for a valid session. Ajax requests in Rails also contain a session identifier. And you should checkwhether the logged in user has appropriate privileges to perform that action. Moreover, you can make sure that the request really is an Ajax request by using the verify method at the top of your controller.
It is typical for Ajax applications to store parts of the state on the client side (the name of the current project, for example), and sometimes parts of the application logic resides inJavaScript code on the client side, as well. As with all input, you should always distrust the state that comes from the client. You should minimize the amount of application logic on the client.
