Download to read offline
Modern apps-and-security-consideration
- 1. Modern JS Appsand Security Considerations October, 2018
- 2.
- 3. Manish Shekhawat Senior Manager– Experience Technology (XT) Vikash Bhardwaj Director – Experience Technology (XT)
- 4. 4 © Copyright Publicis.Sapient| Confidential Agenda 1. State of Modern JS Apps 2. Cogs of the Modern Application System 3. Types of Flaws in System 4. Types of Vulnerabilities and Attacks 5. Finding Vulnerabilities 6. Tools to Fix Vulnerabilities 7. Security as part of System Design 8. Auditing Architecture Security 9. Demo 10. Take-aways
- 5. 01 State ofModern JS Apps
- 6. 6 © Copyright Publicis.Sapient| Confidential Modern web applications have higher user expectations of rich user experience with speedy delivery of meaningful content. Today's web apps are expected to be usable 24/7 from virtually any device or screen size. Applications must be secure, flexible, and scalable. https://docs.microsoft.com/en-us/dotnet/standard/modern-web-apps-azure-architecture/modern-web-applications-characteristics
- 7.
- 8. 02 Cogs ofthe Modern Application System
- 9. 9 © Copyright Publicis.Sapient| Confidential Sample Modern Universal JS Application Architecture * Delete This Page Before Circulation Message Broker API Gateway App Server
- 10. 03 Types ofFlaws in System
- 11. 11 © Copyright Publicis.Sapient| Confidential Architectural Design Flaws Implementation Defects Human Err! Types of Application Flaws leading to Security Breach * Delete This Page Before Circulation
- 12. 04 Types ofVulnerabilities and Attacks
- 13. 13 © Copyright Publicis.Sapient| Confidential XSS Click-Jacking Expression/CSS/Attribute Injection Directory Traversal Attack Remote Memory Exposure Regex DoS Script Injection SQL Injection Typo-Squatting DOM Clobbering Information Leaks while logging Types of Attacks * Delete This Page Before Circulation
- 14.
- 15. 15 © Copyright Publicis.Sapient| Confidential Npm audit Retire.js WPScan OWASP Top 10 Burp Suite OWASP ZAP API W3AF SAST and DAST before Build Manual Audits Observatory by Mozilla Snyk Hookish Chrome Extension Tools to find Vulnerabilities * Delete This Page Before Circulation
- 16. 06 Tools toFix Vulnerabilities
- 17. 17 © Copyright Publicis.Sapient| Confidential Use Linting and ‘use strict’ Encode HTML and URLs Sanitize Inputs JSON.parse Whitelisting No memory Leaks Limiting information in Logs Secure, HttpOnly cookies Cookies with domain scoped and for limited time Remove unnecessary headers Use Oauth 2.0 or 2-way Authentication with refresh tokens Know your App – Input, Output, Behaviour in different situations Don’t Eval Best Practices come handy * Delete This Page Before Circulation
- 18. 18 © Copyright Publicis.Sapient| Confidential CSP CSRF HSTS X-Frame-Options X-XSS-Protection X-Content-Type-Options XSSFilters/Sanitize React-helmet Tools of the Trade * Delete This Page Before Circulation
- 19. 07 Security aspart of System Design
- 20. 20 © Copyright Publicis.Sapient| Confidential Modern Application Systems should be designed secure from ground up. Architectural design vulnerabilities should be avoided since the design phase Each Layer of the System should be made secure and should not be the SPOF for application even in case of Security Breach Architects/Developers should list down all the possible inputs and outputs within the App. Define Workflow for developers with daily touchpoint on Security run. ZAP API integration in CI/CD.
- 21. 08 Auditing ArchitectureSecurity
- 22. 22 © Copyright Publicis.Sapient| Confidential Done by dedicated Security Experts Involve System Architects Methodologies Data Flow Diagrams Microsoft SDL – Threat Modeling Tool Control Flow Diagrams Cigital Threat Modeling Tool Tools Burp Suite OWASP ZAP API Manual Code Audit Audit Application Architecture Security * Delete This Page Before Circulation
- 23.
- 24.
- 25. Remember, A lotcan go wrong. Security is not just a NFR of an Application. If breached, it could cost sensitive data leaks, money, jobs, brand reputation and many times the whole Business.
- 26. 26 © Copyright Publicis.Sapient| Confidential Include Security considerations as part of System Architecture Design. Avoid security specific flaws in Architecture as the impact of vulnerability in architecture and cost of fixing them is high.
- 27. Your Application shouldnot trust anybody – Build a Pessimist, Distrustful, Skeptical Application to make it secure.
- 28. 28 © Copyright Publicis.Sapient| Confidential Validate and Sanitize Inputs. Encode and Encrypt data during transit.
- 29. Set Appropriate Headers. Don’tLeak Sensitive PII information in Logs.
- 30. 30 © Copyright Publicis.Sapient| Confidential Use proven libraries for session management, don’t invent one unless you are a security and session management expert
- 31. Think like ahacker, just don’t overdo it! Start thinking in Graphs and Trees of possible attack paths. Security Audit Checklists are limiting. Know your App inside out.
- 32. 32 © Copyright Publicis.Sapient| Confidential Security is not a post implementation affair. Security should be an everyday job for developers given they are equipped with best practices and tools.
- 33. © Copyright Publicis.Sapient| Confidential
Editor's Notes
- #5 Chatbots, IoT Apps, Universal Apps, etc. JS can modify environment/DOM Can only access web resources if on client but can access server resources if run on backend Lots can go wrong Application, Presentation, Session, Transport, Network, Physical layer Design Systems to be secure from ground up There could be 2 types of flaws in an application : implementation security vulnerability or Architecture design vulnerabilities Implementation bugs could be identified and fixed and have limited area of impact but if the architecture is susceptible to security attacks, it could cause bigger impact. Think like an attacker is suggested but could take a toll on your thinking and we don’t want to be influence by the dark side, do we? White Hats, Hats off to you, guys…. How do you keep yourself sane when the motivation are different for black vs white hats : money, destruction, power vs responsibility, protection, rights. Security implementation is done linear with a checklist and at specific places, thinking of the boundaries and boxes involved while attacker think in Graph, they write algorithms thinking in Graph usually which has more paths and tress to finally reach the gold. Know your app : what does the app take as input and from whom? What does it return as output? What is the intended behavior of your app in a given situation? Inputs : Query Params, URL, HTTP Verbs, cookies, headers, file upload, thirdparty website/vendor integrations, emails, forms, browser storages XSS Validations, Don’[t use eval Sanitze in settimeout, setinterval or any function for that matter which takes input and executes code as string Validate and sanitize all user inputs, (xss, express-validator) Encode output Set appropriate headers : Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Content-Secutiry-Policy (Helmet) CSRF – use tokens (csurf library) Session management – don’t expose session tokens in urls, set expiry time on session token, refresh tokens,HTTPS, permission, Hash password with salt –use bcrpyt or 2-way authentications like google, use Oauth, passport, don’t create your own authentication algorithm and session token generate if you are not sure of complete implementation details of Authentication and authorizations because bugs in such sytems are not tolerated and could damage a lot. Cookies should beset secure or HttpOnly with scoping to specific domain/subdomain and expires Use strict mode, help in identifying silent errors not exactly for secutiry but helps in written better code with best practices ultimately leading to secure code as well. Infromation disclosure – logging error is helpful but sometimes logging more than what is intended could give away information to hackers. Errors/logs displayed in console should be limited without any data information. Remove the unnecessary headers like X-Powered-By header, considerin you are telling the attacher that I am using express, please find vulnerability around that. Not that removing it will stop attack but could help attacker google more and learn more at least. Don’t expose PII data –Sensitive Data Exposure. Encrypt data in transit, don’t store unnecessary user data if not required by your app, don’t store user information in browser storages as well those too can be accessed by XSS attacks. Retire.js Take aways Security is not just a NFR of an application, it could cost data leaks, money, jobs, brand reputation and many times the whole business Security is not a post implementation affair, Think like an attacker but don’t overdo (personal advice) Security is implement through best practices and always from starting of the project It is not always about your own code but could be because of npm usage where vulnerable packages Dirctory traversal vulnerability %2e in the path through curl and land on directory path - be aware of encoding Encoding provided in packages is not enough because browsers tend to be more smart and try to do more than you think thus add manual encoding for few specific things. Regex denial of service ends with ($) or catastrophic back tracking as regex are greedy, takes time to process and blocks the thread DOM clobbering Remote memory exposure through Buffer as buffer allocate new available memory and doesn’t resets. Through JSON without quotes as input/ouput and could expose memory details Consider takeaways Encoding HTML, URL Whitelist instead of blacklist Control regex input length npm packages – find,let the owner know, upgrade regularly, break build if vulnerability detected Npm is using ^Lift and nsp now to keep npm packages secure by identifying vulnerabilities Typosquatting npm package names cross-env vs crossenv WPScan if you use Wordpress as CMS Vulnerability in frameworks and CMS Misplaced trust in client, server, layers or users Browser implementation errors as loopholes OWASP top 10 Burp Suite OWASP ZAP API W3af Automated scans and manual runs https://observatory.mozilla.org/analyze/jsfoo.in Snyk – they have discovered and documented vulnerabilities in many web application. Trust nobody – what a pessimist! Never make a single mistake – Easy Right! Security should be everyday job for developers given they are equipped with best practices and tools. React escapers a hy values embedded in JSX before rendering. This prevent XSS But SSR – great for performance, SEO – initial state – replace /</g, innerHTML - dangerouslysetInnerHTML, eval based injection – JSON.parse, CSS-inJS – sanitize, are still vulnerable React-helpmet Serialize – escapes Xssfilters – more flexibility but self configure Ahamed Nafeez - Hookish chrome extension Object.defineProperty(objectName, One, { get: function(){return ‘A’} }) objectName.One// ‘A’ Lock object value not to be changed : Object.preventExtensions(objectName) cannot set property new Object.seal(ObjectName) cannot delete Object.freeze(objectName) Cannot change property Document.domain If(top!=self) UI redressing attacks JS frame busters top.location = self.location <form name=“self” location=“javascript:alert(“hacked”)”></form> Self.location now Object.getOwnPropertyDescriptor(document, ‘domain’) Configurable Location.href is not configurable but could be source of dom xss HSTS – 301 redirect – Strict Transport Security Preload JSON-P withCredentials:true CSP - BATSHIELD
- #7 Chatbots, IoT Apps, Universal Apps, etc. JS can modify environment/DOM. Can only access web resources if on client but can access server resources if run on backend. A lot can go wrong
- #10 Application, Presentation, Session, Transport, Network, Physical layer