Learn about common web application security threats and how to avoid them in your code. We will discuss general security challenges and high level principles, example attacks, social engineering, browser security and more, providing best practices along the way. This talk is a good review of the topic for experienced developers, and is highly recommended for new programmers who have not been exposed to web application security challenges in the past. This session is not specific to any particular server-side technology. We will not discuss network security (routers, DMZs) or OS security, as this talk is focused on web application developers.

1. Web Security for App
Developers
Pablo Gazmuri - @PGazmuri
BlueMetal Inc.
2015

2. Agenda
• We will discuss:
o Web Application Security Challenges
o Example Attacks
o Social Engineering
o Browser Security
o Security Principles
o Best Practices
• We won’t discuss:
o Network Security (Routers, DMZs, etc…)
o Software Platform / OS Issues (buffer overflows)

3. Top 10 Challenges
• SQL/XPath/Shell/LDAP Injection
• Cross Site Scripting (XSS)
• Authentication / Session Management
• Insecure Direct Object References
• Cross Site Request Forgery (CSRF)
• Security Misconfiguration
• Insecure Cryptographic Storage
• Failure to restrict URL access
• Insufficient Transport Layer Protection
• Unvalidated Redirects and Forwards

4. Misc. Challenges
• Social Engineering
• Code-specific Exploits
• Password Cracking
• Click Jacking
• DOS attacks

5. Example Attacks
• User Account Hijacking
o Phishing
o XSS via JS Injection or CSRF
o Network Sniffing
o Social Engineering
o Password Cracking
o Code-Specific Exploits

6. Example Attacks
• Website Content Takeover
o Hijack Admin Account
o XSS
o Code Specific Exploits

7. Example Attacks
• Data Theft
o Unsecured Services
o Hijack Account
o XSS to read data on page and phone home

8. Example Attacks
• Click Jacking
o Common Example: Facebook “Likes”
o Loads a transparent iframe over the page
o Positions the frame so that “like” is always
under the mouse cursor.
o Prevent this by “FrameBusting”

9. Example Attacks
• Denial of Service
oUnsecured Heavy Processing
• SQL/XPath/Shell/LDAP Injection
oAlways due to poor coding techniques

10. Social Engineering
“It is much easier to trick someone into giving a password
for a system than to spend the effort to crack into the
system.” – Kevin Mitnick
He’s right: 90% of users will give up their passwords for a
chocolate bar.

11. Social Engineering

12. Social Engineering
• Phishing
• Pretexting
• Diversion
• IVR Phishing / Vishing
• Baiting
• Quid Pro Quo
• Exploiting Current Events

13. Browser Security
• CORS Requests
o Cross Origin Resource Sharing
o Cross-Site Requests Controlled by Access-Control headers
o Not supported by all browsers
• IE7- can only use jsonp – GET only
• IE9- ignores Access-Control headers
o IE8+ uses XDomainRequest object
• This is different from chrome, firefox, safari
• Requires custom AjaxTransportHandler to get jQuery ajax working

14. Browser Security
• CORS Response Headers
o Access-Control-Allow-Origin
o Access-Control-Allow-Credentials
o Access-Control-Allow-Headers (preflight only)
o Access-Control-Allow-Methods (preflight only)
o Access-Control-Expose-Headers
o Access-Control-Max-Age (preflight only)
• CORS Request Headers
o Origin
o Access-Control-Request-Method (preflight only)
o Access-Control-Request-Headers (preflight only)

15. Browser Security
• Rapid Request Blocking
o Currently in Chrome only.

16. Browser Security
• Know Your Cookie Types
o Session
o Secure
o HttpOnly
o HostOnly
• Understand Cookie Domain and Path Settings
• Cross Site Cookie Acceptance
o Requires same subdomain across sites
o Requires proper Domain cookie setting
o Request must be made “With Credentials”

17. Security Principles
• Apply Defense in depth
• Use Positive Security Model
• Fail Securely
• Run with Least Privilege
• Avoid Security by Obscurity
• Keep Security Simple
• Detect Intrusions
• Don’t Trust Infrastructure or Services
• Establish Secure Defaults

18. Best Practices
• Use HTTPS wherever possible
o Prevents sniffing of login data, session cookies and application output
• Design Cookies for Security
o Auth Cookies: HttpOnly, Session (Status may be kept in separate cookie for
client rendering of login details)
o Auth Cookies should not be “reusable” and should expire
o Auth Cookies should include an encrypted hash for verification

19. Best Practices
• Prevent HTML /JS Injection Attacks
o ALWAYS HTML Encode data output
o If you must allow user-generated HTML on the page, filter out <script>, <object>,
<embed> and others. See Google-Caja
o When accepting URLs as input:
• scrub for “javascript:” (harder than it looks)
• HTML Encode URL on output
• Require CAPTCHA to prevent spamming

20. Best Practices
• Prevent Injection Attacks
o Don’t execute query text directly / Know how to escape
o Use appropriate DB abstraction tech
• Stored procs
• ADO.NET SqlCommand
• LINQ / EF

21. Best Practices
• Use HTTP Frame-Options Header
• Use Anti Anti Frame Busting
o Prevent you page from being loaded as an iframe
o Prevents Click Jacking and Iframe based XSS/CSRF

22. Best Practices
• Never rely on the client
o Always implement server side validation
o Remember
• End users can inject JS into the page at any time
• End users can alter HTTP requests including cookies and headers
• Users can view unsecured requests on the local network
• If you must allow CORS, keep security tight:
o Only set Origin, Method and Credentials headers to minimally required values
o Alternatively: create a backend proxy and don’t support CORS.
o DO NOT create a blanket rule to output Access-Control-Allow-Origin: * on all
responses. This is lazy and dangerous.

23. Best Practices
• Rethink what a “strong” password is:
o If I have to write it down, it’s not secure!
o Must have uppercase and number?
• Most popular password: Password1
• Is that really “strong”?
o Let people choose “weak” passwords, but warn them it is weak.
• A long password with no numbers/symbols is just as good as a short
password with numbers/symbols – consider password Entropy as a
measure of strength.
• Include check for zip code, phone numbers, name and the text “password”
o Suggest longer passwords that relate to a personal story:
• “I got married in Maine this summer”:
o MaineWedding2012
o I can remember that!
o It’s long and won’t be guessed easily…

25. Best Practices
• Prevent dictionary attacks:
o Reset password after X bad logon attempts
o Or
o Create a login “sandtrap”:
• Slows bad login attempts by an random amount of time
• Makes dictionary login attacks very difficult
o Use CAPTCHA
• Follow Password Storage Best Practices:
o Do not store passwords unencrypted
o In fact, do not store passwords at all: store a non-reversible encrypted hash
o And use a salt (so if the same password is used by another user it will have a
different hash, because a unique salt is included in the hash).

26. Best Practices
• Avoid using security questions:
o They are almost universally terrible:
• Mother’s maiden? Public Record.
• Make of first car: too few options (maybe a dozen?)
• Favorite pet: I can figure this out in one phone call
o Use email-based password reset instead
o If you must, use known acct. information (last 4 SSN digits)

27. Best Practices
• For sensitive or computationally expensive operations,
consider “signing” requests to ensure legitimate use.
o Require an expiring hash generated using a private key to be included with
requests
o End users will be unable to forge altered requests for that resource
o Example: Text-to-image functionality
• Don’t want to stop anonymous users from accessing
• Don’t want others to reuse this service to generate their own text
• Requiring a hash of the text being written to an image to be included in
image requests prevents creation of “unauthorized” images.
o Example: CSRF
o Important with some cloud apps, can help prevent DOS attacks.

28. Best Practices
• Think VERY hard about security when creating or
maintaining sensitive functionality:
o Login, authorization, reset password, forgot password, create account, join email,
etc….
o Don’t round-trip sensitive data if you can help it
o Many security holes are created during maintenance.
• Do not rely on obscurity to secure your application
o Your application should remain secure, even if the source code leaks.
• If not, something is very wrong with your architecture
o Don’t rely on “hidden” URLs
o Secure all services at the request level

29. Best Practices
• Do not display detailed error messages in Production
o Override default error handler to return 200 OK responses
o Always provide a customized error page that is the same for all errors
o Consider sandtrap for error handling
• Do not use DEBUG binaries in production
o Also, ensure the following in web.config:
<configuration>
<compilation debug="false"/>
</configuration>

30. Best Practices
• Perform code audits / reviews for application specific
issues
o This is hard – Consider static analysis tools such as CAT.NET
o It’s very easy to create a security hole, much harder to discover them.
o Examples:
• Password Reset Question Answer written to hidden input on page
• Authorization cookie not cryptographically verified (I can be logged in as
anyone!)
• Creating an account using an already used email address takes over that
account.
• Limit access to production data
o Use fake data in lower lifecycles
o Apply Principle of least privilege

31. Social Engineering
Best Practices
• Establish “framework of trust”
• Identify Sensitive Info
• Establish Security Protocols
• Train Employees in those Protocols
• Secretly Test the Framework

32. Social Engineering
Best Practices
• Consider using SiteKey or other verification methods
• Destroy your trash
• Educate end user and employees
• Don’t inadvertently train users to engage in bad behavior

33. OWASP Cheat Sheets
• https://www.owasp.org/index.php/Secure_Coding_Cheat
_Sheet
• https://www.owasp.org/index.php/Attack_Surface_Analys
is_Cheat_Sheet
• https://www.owasp.org/index.php/XSS_Filter_Evasion_C
heat_Sheet
• https://www.owasp.org/index.php/HTML5_Security_Che
at_Sheet