1. It’s always better live. MSDN Events Security Best Practices Part 2 of 2 Reducing Vulnerabilities using Visual Studio 2008

2. Cross Site Scripting (XSS) Utilize Anti-Cross Site Scripting Library Also include a consistent architectural approach ensuring the following: Input Validation Strong output encoding Don’t use literal character exclusion Ex. Only checking for “ ”, etc.. Use a combination of client side and server side validation Remember: INPUT IS EVIL! Validate what is good, not what isn’t Input is anything coming from the browser

3. Cross Site Scripting XSS Solution Demo

4. Cross Site Request Forgery Utilize Reverse Turing Techniques Implement Captcha to protect against bots Conduct vulnerability tests Insert custom random tokens into every form and URL that is automatically submitted by the browser and validate when accessing Tokens on a function level maximize security Re-authenticate for sensitive data or value transactions. Set a ViewStateUserKey for each page

5. Cross Site Request Forgery Cross Site Request Forgery Solution Demo

6. Injection Flaws Constrain and “Sanitize” input Data Use type-safe parameterized queries, or stored procedure’s for data access Declare type Constrain length Enforce least privilege when connecting to DB Avoid detailed error messages Do not rely solely on Replace() functions Do not send dynamic queries

7. Injection Flaws Injection Flaws Solution Demo

8. Malicious File Execution Use identifier and lookup method to access files Strongly validate file uploads using “accept known good” strategy Hide server-side filename’s from the user Add firewall rules to prevent web servers from making new connections For high value systems, isolate the web server in its own VLAN or private subnet

9. Malicious File Execution Ensure that file and stream functions are carefully vetted Ensure that user input is not supplied to a function which takes a filename argument Design applications to be segmented trust Ensure most of the application exists in the lowest possible trust state.

10. Insecure Direct Object Reference Avoid exposing direct object references to users by using index, map, or other indirect method If necessary, ensure authorization Utilize ashx files Establish standard object references Avoid exposing private object references Validate private object references with “accept known good” approach Verify authorization Only allow authorized records to be displayed

11. Insecure Direct Object Reference Insecure Direct Object Reference Solution Demo

12. Information Leakage and Improper Error Handling Verify application does not leak information through error messages or other means Ensure that dev team shares common error catching / messaging approaches Disable or limit error handling Do not display debug information to end users Ensure proper configuration of web.config Use identical error messages for many transactions Use “Invalid Username OR Password” instead of field specific errors

13. Information Leakage and Improper Error Handling Information Leakage and Improper Error Handling Solution Demo

14. Broken Authentication and Session Management Verify the application properly authenticates users and protects their credentials All passwords should be hashed with a SALT so identical passwords hash differently Careful and proper user of session management mechanisms should significantly reduce risk

15. Broken Authentication and Session Management Broken Authentication and Session Management Demo

16. Insecure Cryptographic Storage Ensure encrypted data is actually encrypted and implemented properly Only someone with a PhD in Math specializing in cryptography should generate cryptographic algorithms. Fully utilize encryption standards Utilize the System.Security.Cryptography ASP.NET Library Utilizes Triple Data Encryption Standard algorithms (Triple DES) Use only publicly approved algorithms such as: AES, Triple DES, RSA public key cryptography, and SHA-256 or better for hashing

17. Insecure Cryptographic Storage Generate Keys offline and securely store private keys Ensure infrastructure credentials are securely encrypted Never store unnecessary data or the primary account number SALT passwords to ensure uniqueness See PCI DSS Guidelines and implement controls as necessary www.pcisecuritystandards.org

18. Insecure Communications Use SSL for communications with end users All authenticated traffic needs to go over SSL Ensure proper implementation Ensure communications between web servers and database systems are protected via their transport layer Don’t rely on browser built in notification icon as a security indicator of your application Must implement properly

19. Failure to Restrict URL Access When enabling URL access consider the following: Ensure control matrix is part of the architecture Ensure that all URLs and business functions are protected by an access control mechanism Must verify user prior to any processing taking place Authorization checks must be frequent Do not assume user’s access knowledge Block access to file types that your application should never serve

20. Failure to Restrict URL Access Failure to Restrict URL Access Solution Demo