XSS, CSRF, Injections and other forms of common web application exploitations are disclosed and discussed in order to further programmers' understanding of these easily preventable security issues.
Plaintext passwords stored in the database. Never do this. Period. As a developer, you’re asked to do this so that people can easily retrieve their passwords via email or a call to support. Just say no. Not only do you get exposures like this but anyone who has access to the database, and the plaintext passwords within, very likely will have access to other website accounts where the users likely use the same low-security passwords.
Low-security passwords. If your data has some modicum of secrecy or value, enforce a password security requirement — numbers, symbols, capitals, etc. As shown in the article, many of the passwords exposed were easily guessable or dictionary hackable even without the SQL injection.
SQL injection. You can see in the URL from the screenshot how the researcher exposed the most important flaw, SQL injection, that led to the previous two. He closed out one query in the URL and opened up his own (likely selecting the usernames and passwords from a guessed table name like, oh, “users” or “admin”, and selecting them by their userIDs). This is easily stopped in any scripting language by escaping out any variables you take from the user and sanitizing that input before using it in your query. Parameterized queries are even better.
Those are three dangerous flaws that many sites suffer from but it is unfortunate to see all three exposed at once and in a large governmental organization.