Housekeeping before Deploying - Disable trace, , etc
Use Sessions, but Not Cookie-less Sessions
A few notes about the article:
XSS (Cross-site Scripting) is something that is very important, especially for forum and blog sites. Web Developers are to assume the worse about their visitors, and should always try to encode user input when necessary. I found it interesting that there were reports of a loophole, even though ASP.NET has a built in mechanism to prevent XSS. The loophole consisted of a null character (%00), which if inserted into the <Script> tag, could bypass detection. (This has since been hot-fixed, but nevertheless demonstrates the importance of the Server.HtmlEncode() method).
When talking about SQL Injection attacks, the author gave examples of using the Parameters object to combat any attacks, but never mentioned Stored Procedures. Although using Parameter queries is head and shoulders above inline SQL, I think it's better practice to use SP's, if the situation allows.
Lastly, the author mentions the use of Hashing to store passwords instead of plain text. He goes on to say:
"This is a dangerous thing to do; if your SQL Server is compromised, you run the risk of exposing all the passwords. (There are those who argue that if your database server is compromised, it doesn't matter how you save your passwords?they are no longer secure)."
Ok, great, Hash away. But there isn't much explanation of WHY the argument of, "Well, your DB has been compromised, so you're SOL either way" is wrong. Not that I feel hashing is a waste of time, because it isn't; but I'd like to hear a better explanation of WHY it isn't.
Previous Topic
