Based on the assessment we have done over the past couple of years, the top two places to check for cross-site scripting (XSS) flaws are login page (of course) and application-level error pages. Login pages make sense to check – they are the gateway to the application and they are accessible to unauthenticated users. If you can find an XSS flaw on the login page it can often be used in direct support of phishing scams where spam emails contain malicious links to the login page.
What we also found that surprised us was that there are a lot of applications with vulnerable generic error pages. Not HTTP or web server error pages, but pages included in an application that can display generic error messages. All too often those pages have URLs like http://www.server.com/TheApplication/error.jsp?msg=Description+of+error+condition. For developers fighting a deadline this looks like a great way to save some time, but all too often we find that the “msg” parameter gets echoed directly into the center of a generic site page. D’Oh! What you end up with is a site with a publicly-accessible page with little content on it (to save room for the error message) that an attacker can use to include whatever malicious content they like. If the page can be served over HTTPS that is even better – for the attacker.
So after you are done beating up your login routine looking for XSS and SQL injection flaws, poke around to see how the application reports errors. You just might be surprised at what you find.
dan _at_ denimgroup.com