My honor to kick off with the first programming error on the Top 25 list. Ranked number 1 on the list is the Cross Site Scripting issue.
Cross Site Scripting like many other Web security problems is caused by simple flaws related to user input but the potential attack scenarios can be diverse and the fix is not easy. The fundamental flaw of Cross Site Scripting is malicious user input got sent from the server to the victim's browser, all within the HTTP response that the browser is ready to "render" on screen for the user. The browser cannot distinguish between the real site content and user input that actually "means something malicious". The malicious code gets "rendered" by the browser as HTML or scripting command while it should just be a plain looking text string on the screen.
Imagine a log in page where the user can type in user name and password. When you type in user name "Jason" and a password then press enter, the website might respond with "Invalid login information - username: Jason". Now, think maliciously for a sec, what if the input is <img src="http://sans.org/evil.jpg">? When the login error message get displayed, the message becomes "Invalid login information - username: <img src="http://sans.org/evil.jpg">" The <img> tag gets rendered (or executed) by the browser and this is how cross site scripting works. In specific, this is a reflected cross site scripting attack.
With the vulnerabilities so wide spread, how do we fix it? Just filter out that <> characters? Nah... Wrong answer. Effective XSS prevention requires both input validation and output encoding.
Input validation get rid of all the noise and reduce overall security exposure but input validation is hard, so hard that it is impossible to completely filter out XSS. Check into XSS cheat sheet and you will know why. Another thing thats really killing input validation is the increasing sources of information in web applications. With the mashup Web model, you have sources that you don't even know you have and absolutely no idea whether they are fully validated or not. Output encoding comes to the rescue. Before output, all those <> and offending characters are mapped to another representation so the browser knows to display them on screen instead of executing them.
Output encoding sounds easy but you need to do it right and do it consistently in order for it to work. As a start, set the page encoding using meta tag, this ensuring the browser is displaying the encoding you intend to deal with. The actual encoding is context specific, you have to do the right encoding for different part of the HTML document. The XSS Prevention Cheat Sheet has detailed instruction on what to do where in the HTML page. Rule #1 and Rule #2 in the cheat sheet will serve you for 95% of the situations but be aware there are 5% of situations where the other rules applies. Various development framework have different functions or API to handle the output encoding process.
Consistency is another big factor in wining the XSS game. Make sure all developers have the same understanding and preferably use the same common API to deal with this complex output issue. There are projects like OWASP ESAPI that provide usable API to take the guess work out of the developer's hand.
Since one of the most common goal of XS attacks are to steal session cookie. The HTTPOnly cookie flag was developed specifically to cut down on this risk. However, keep in mind that it only cut down on the risk but is not an all encompassing solution.
Hope you enjoyed reading this post, it's a long post but as 1st place in the Top 25 list, I think XSS deserve this much verbiage. We will try to keep the length reasonable for the lower ranking issues. :-) Feedback always welcomed.