Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Web Security for App
Developers
Pablo Gazmuri - @PGazmuri
BlueMetal Inc.
2015
Agenda
• We will discuss:
o Web Application Security Challenges
o Example Attacks
o Social Engineering
o Browser Security
...
Top 10 Challenges
• SQL/XPath/Shell/LDAP Injection
• Cross Site Scripting (XSS)
• Authentication / Session Management
• In...
Misc. Challenges
• Social Engineering
• Code-specific Exploits
• Password Cracking
• Click Jacking
• DOS attacks
Example Attacks
• User Account Hijacking
o Phishing
o XSS via JS Injection or CSRF
o Network Sniffing
o Social Engineering...
Example Attacks
• Website Content Takeover
o Hijack Admin Account
o XSS
o Code Specific Exploits
Example Attacks
• Data Theft
o Unsecured Services
o Hijack Account
o XSS to read data on page and phone home
Example Attacks
• Click Jacking
o Common Example: Facebook “Likes”
o Loads a transparent iframe over the page
o Positions ...
Example Attacks
• Denial of Service
oUnsecured Heavy Processing
• SQL/XPath/Shell/LDAP Injection
oAlways due to poor codin...
Social Engineering
“It is much easier to trick someone into giving a password
for a system than to spend the effort to cra...
Social Engineering
Social Engineering
• Phishing
• Pretexting
• Diversion
• IVR Phishing / Vishing
• Baiting
• Quid Pro Quo
• Exploiting Curr...
Browser Security
• CORS Requests
o Cross Origin Resource Sharing
o Cross-Site Requests Controlled by Access-Control header...
Browser Security
• CORS Response Headers
o Access-Control-Allow-Origin
o Access-Control-Allow-Credentials
o Access-Control...
Browser Security
• Rapid Request Blocking
o Currently in Chrome only.
Browser Security
• Know Your Cookie Types
o Session
o Secure
o HttpOnly
o HostOnly
• Understand Cookie Domain and Path Set...
Security Principles
• Apply Defense in depth
• Use Positive Security Model
• Fail Securely
• Run with Least Privilege
• Av...
Best Practices
• Use HTTPS wherever possible
o Prevents sniffing of login data, session cookies and application output
• D...
Best Practices
• Prevent HTML /JS Injection Attacks
o ALWAYS HTML Encode data output
o If you must allow user-generated HT...
Best Practices
• Prevent Injection Attacks
o Don’t execute query text directly / Know how to escape
o Use appropriate DB a...
Best Practices
• Use HTTP Frame-Options Header
• Use Anti Anti Frame Busting
o Prevent you page from being loaded as an if...
Best Practices
• Never rely on the client
o Always implement server side validation
o Remember
• End users can inject JS i...
Best Practices
• Rethink what a “strong” password is:
o If I have to write it down, it’s not secure!
o Must have uppercase...
Best Practices
• Prevent dictionary attacks:
o Reset password after X bad logon attempts
o Or
o Create a login “sandtrap”:...
Best Practices
• Avoid using security questions:
o They are almost universally terrible:
• Mother’s maiden? Public Record....
Best Practices
• For sensitive or computationally expensive operations,
consider “signing” requests to ensure legitimate u...
Best Practices
• Think VERY hard about security when creating or
maintaining sensitive functionality:
o Login, authorizati...
Best Practices
• Do not display detailed error messages in Production
o Override default error handler to return 200 OK re...
Best Practices
• Perform code audits / reviews for application specific
issues
o This is hard – Consider static analysis t...
Social Engineering
Best Practices
• Establish “framework of trust”
• Identify Sensitive Info
• Establish Security Protocol...
Social Engineering
Best Practices
• Consider using SiteKey or other verification methods
• Destroy your trash
• Educate en...
OWASP Cheat Sheets
• https://www.owasp.org/index.php/Secure_Coding_Cheat
_Sheet
• https://www.owasp.org/index.php/Attack_S...
Web security for app developers
Upcoming SlideShare
Loading in …5
×

Web security for app developers

6,427 views

Published on

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.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Web security for app developers

  1. 1. Web Security for App Developers Pablo Gazmuri - @PGazmuri BlueMetal Inc. 2015
  2. 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. 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. 4. Misc. Challenges • Social Engineering • Code-specific Exploits • Password Cracking • Click Jacking • DOS attacks
  5. 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. 6. Example Attacks • Website Content Takeover o Hijack Admin Account o XSS o Code Specific Exploits
  7. 7. Example Attacks • Data Theft o Unsecured Services o Hijack Account o XSS to read data on page and phone home
  8. 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. 9. Example Attacks • Denial of Service oUnsecured Heavy Processing • SQL/XPath/Shell/LDAP Injection oAlways due to poor coding techniques
  10. 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. 11. Social Engineering
  12. 12. Social Engineering • Phishing • Pretexting • Diversion • IVR Phishing / Vishing • Baiting • Quid Pro Quo • Exploiting Current Events
  13. 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. 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. 15. Browser Security • Rapid Request Blocking o Currently in Chrome only.
  16. 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. 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. 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. 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. 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. 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. 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. 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…
  24. 24. 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).
  25. 25. 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)
  26. 26. 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.
  27. 27. 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
  28. 28. 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>
  29. 29. 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
  30. 30. Social Engineering Best Practices • Establish “framework of trust” • Identify Sensitive Info • Establish Security Protocols • Train Employees in those Protocols • Secretly Test the Framework
  31. 31. 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
  32. 32. 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

×