STICK TO FUNDAMENTALS
Do Ajax applications even require new security solutions? The problem still comes down to validating user-provided input, and ensuring that whatever is sent to the user conforms to some valid representation format. The user-provided input might take on slightly different shapes in an Ajax world (such as serialized JSON), and responses back to the user might not be fully formed HTML (they could be serialized XML or JSON). These changes imply complexity, but not an overarching change in security; solutions remain relatively the same.

Scrubbing user input, validating system output. Regardless of the mechanisms by which data reaches a server, there are only three things an application will do with it: store, modify or render it. Server-side validation should be specific to how the data will be used: SQL scrubbing, type enforcement and HTML encoding, respectively. Sometimes a piece of data will be used in multiple ways during a single request, and it follows that each appropriate type of validation should be performed.

We can categorize potential system outputs four ways:

1. Rendering as HTML. HTML representation is constructed either through string manipulation or a templating engine, and rendered to the browser.



2. Executing as SQL. If we consider the application to be the code running in a process controlled by the Web server, SQL queries are just another output from the application to be consumed by the database server. SQL queries should be constructed using high-level tools that protect against SQL injection through parameterized queries.



3. Rendering to the browser in non-HTML format. Generally, exporting a textual representation of structured data as JSON, XML, YAML, a microformat or other, as well as any of the many MIME types.



4. Saving to server file system. Data appended to a file-based data store or other file-based format.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   7  |   8  |   9  |   10  |   NEXT PAGE  >