ATG Security

World-facing websites always have to be written carefully in order to prevent malicious attacks. There are tons of additional vulnerabilities and attack vectors which need to be addressed as well, but in this post I’m going to talk about the two most common: Cross Site Scripting (XSS) and SQL Injection.

If you already know what these are, feel free to skip down a bit to the section where I talk about where ATG Dynamo helps and where there are still some gaps.

Cross Site Scripting is essentially when someone malicious gets your website to source in their content, from their site usually (hence the “cross site”), to what you serve to your users. This can take many forms including embedding a malicious page inside an existing frame in your website, sourcing in javascript which runs on your user’s computer as if it had come from your site, embedding an inappropriate image in a page, or using tricks (or javascript) to redirect the user from your site to a competitor or even a site that LOOKS like yours, but isn’t.

It is an attack against your users, not your servers.

Crackers can use these types of attacks, either through carefully crafted links or through user contributed content (comments, posts, reviews, etc…) to deface a website, use Javascript to steal cookies and take over a session (stealing credit card information, login and passwords, account data, or placing fraudulent orders), hijacking the user to another site (a competitor or a phishing site), etc… They can even install persistent Javascript that will pass secret data each time the site is visited.

By stealing account information and by placing fraudulent orders these attacks can turn into attacks against your site, secondarily.

Typically these attacks are made by taking advantage of anywhere the website echoes back user input or query/post parameters within the contents of the rendered page. This could be a comment or review function, or even passing a query param along in a hidden form field. There are a million places where sites end up putting request data or un-cleansed data from the database into the contents of a page.

SQL Injection is where a cracker is able to directly manipulate your database. This can be used to bypass authentication mechanisms, delete critical data, or steal confidential information.

This most often happens when form input is used in a database query (select, update, and insert are all vulnerable). By inserting SQL into the form, a carelessly developed site will often pass that SQL directly to the database, where it is executed as if it was the web application running it.

So, now that we’ve covered the mechanisms and dangers of these two types of attacks, let’s talk about how ATG helps, and where there are still security gaps.

ATG automatically escapes output from valueof tags which prevents 95% of the normal issues which would plague a site written in PHP or straight JSP (you aren’t using any inline Java in your JSPs are you?).

One of the biggest, and most common, gaps is the use of:


ATG uses this in the form action attribute in many of their own pages, and it is common to see it commonly used across a site. This allows very simply constructed links (think in phishing e-mail or on a blog or forum site) to include malicious Javascript in a page.

So, if you are outputting anything that may contain user input, from a request or the database, use valueof, or if you can’t, escape it using ATG’s ServletUtils:


Now let’s talk about SQL Injection. ATG’s Repository layer (Data Anywhere) automatically prevents SQL injection. So as long as you are using it, you are safe. If you have to do straight JDBC work, ensure you are using parameterized queries.

There are excellent tools out there for analyzing your code base and application in order to find security issues like these, and others. My two favorites are Fortify which performs analysis of the code, tracing potentially dirty data through it’s lifecycle and identifying issues, and WebInspect which is a penetration testing tool which scans the web site looking for XSS vulnerabilities and other issues.







Leave a Reply

Your email address will not be published. Required fields are marked *

PHP Code Snippets Powered By :