OWASP Top 10

SSL/TLS Certificate Chain Vulnerabilities

- 2 types of Certificate Authorities (CA) => root CAs and intermediate CA's - For an SSL cert to be "trusted" - it has to have been issued by a CA that is included in the trusted store of the device (device = browser usually) - It will follow the trust chain until either a trusted CA is found (at which point it will generate a trusted/secure connection) - or if not trusted CA can be found (you'll get an error) Vulnerabilities - not verifying cert is issued by trusted CA - not verifying allows attacker to present fraudulent cert - not checking expiration date of cert - expired cert can indicate compromised or lack of maintenance - check revocation status - check that cert hasn't been revoked by issuing CA - not checking the chain of trust Regular monitoring/auditing - verify SSL/TLS cert mgmt policies => reviewing policies for cert issuance, renewal, revocation, key mgmt, verifying authenticity of certs - there are SSL/TLS monitoring tools

OWASP Top 10 #10: Server Side Request Forgery

- SSRF => occurs whenever web app fetches remote resource, without validating a user supplied URL - allow attacker to coerce app to send request to unexpected destination (even if destination is - higher risk with cloud and more complex architectures Ex - shopping app has check to see if item in stock - it checks if in stock by sending query to backend REST API. Normal request sends a url in the GET request body - but if an attacker can adjust the payload and put a different URL that the API will call - ( such as http://localhost/admin - it will fetch admin details - forge request and use server to be able to gain permission to admin section - then return results to the user - attacker wouldn't be able to get to localhost/admin just making a request on their own, but they can do it by forging a request through the Network Layer Prevention - segment out remote resource functionality to reduce impact to SSRF - enforce deny by default firewall policy at the network level - log all accepted and blocked network events of firewall Application Layer Prevention - sanitize/validate all input data - enforce URL schema, port , destination - with allow whitelist

OWASP Top 10 #6: Vulnerable and Outdated Components

- app is comprised/built from different components, libraries - application relies on 3rd party libraries - both client side and server side - if you don't scan for vulnerabilities regularly (or subscribe to security bulletin), if you don't fix underlying platforms/frameworks/dependencies - then you're probably vulnerable - typically the components run with the same privilege as application itself, so any type of flaws in the components - can result in serious impacts Ex Apache Struts 2 (2017 had remote code execution vulnerability) - significant breaches on variety of apps around the world Prevention - remove unnecessary features/components - regularly scan/assess 3rd party components - use automated tools to scan the codebase - keep components up-to-date - - use dependabot - stay one step below the bleeding edge (let the newest versions sit for a while)

OWASP Top 10 #9 - Security Logging and Monitoring Failures

- do you do sufficient logging, and do you monitor the logs Best Practices - logins, failed logins, high transaction events - these need to be logged (audit) - logs of API need to be monitored - logs should not just be stored locally, they should be backed up - appropriate alerting thresholds and response escalation process - Attack - appropriate detection and escalation to alert on attacks - If you deploy from lower to higher envs, and the initial logging isn't setup in a test env - then when it makes it to higher env logging won't be setup in prod either Prevention - ensure all login, access control, server-side input validation are logged - ensure enough context/metadata in logs to identify suspicious activity - hold logs long enough for forensic activity - generated in format that log management solution can consume - ensure log data is encoded correctly to prevent injection and attacks on monitoring itself - adopt incident response plan to Ex - healthcare provider had been attacked and leak patient data, but they didn't have sufficient logging to detect this attack. They get told by 3rd party to inform healthcare provider they'd bee breached Ex - airline with data breach of 10 yrs worth of PII breached. Problem occurred at 3rd party cloud hosting and they didn't have sufficient logging - this also falls under this category

OWASP #2: Cryptographic Failures / Sensitive Data Exposure

- focus is related to failures of cryptography - which could lead to sensitive data exposure - always use https - don't roll your own crypto- use trusted libraries - use https on all sites Key Management - key management => is server cert and trust chain validated - store keys in secure location, use strong passwords, rotate keys frequently Automatic Decryption - normal users make request into app, which calls the db to pull credit card #. The CC # is encrypted in the db, but when it's retrieved it's decrypted. - it's good to use encryption, but bad to use automatic decryption - since an attacker can write a SQL injection attack and get out decrypted CC #'s https - if you don't enforce TLS encryption for every page in your app - an attacker can listen/sniff traffic to that page - enforce https on all pages Downgrade Attack - - an attacker intercepts communication and modifies the TLS protocol negotiated and forces the user to use a weaker encryption algorithm and weaker key length than normal - making it easier for attacker to decrypt communication and steal info Prevention => use latest/strongest encryption protocol/algorithm, patch known vulnerabilities - use 2FA to prevent attackers from accessing sensitive info Cryptographic Randomness/Entropy Cryptographic randomness should be used where appropriate, and it should not be seeded in a predictable way or with low entropy - software random # algos use a seed value as a input (can be fixed or from some low entropy software process - if an attacker can find seed value, can predict random #'s). Whereas hardware random # generator rely on physical processes such as electronic/thermal noise, radioactive decay - which are truly random - low entropy can lead to weak keys. OWASP recommends using hw random # generator to generate strong keys Overall Goal - Review app and classify data as sensitive vs non-sensitive data - which will guide you on how strong encryption you need - Don't store sensitive data if you don't need it - data not retained can't be stolen - encrypt all data at rest

OWASP Top Ten #5 - Security Misconfiguration

- have security components within application, but they're not configured correctly (IE - you haven't changed the default password) - #4 was insecure design, but this is if an app is securely designed, but on some implementation step is not configured properly Things to look for - unnecessary features enabled/installed - default pw unchanged - latest security features are disabled (ex - after an upgrade) Ex - your app is being hosted on a server that also hosts a sample app. If the sample app has known vulnerabilities - an attacker can gain access to the sample app and then access to whole server (including your app). This is misconfigured security w/ the sample up app - sample app should be totally removed to remove attack vector - ex => Too much detail in your error message- error message you give to user gives too much info and attacker uses this to attack vulnerability Prevention - look at hardening guides for each framework - and follow those guidelines (Ex - TLS secure settings - Mozilla has a TLS config generator - which helps with secure TLS - gives you an TLS score) - repeatable hardening process that makes it fast/easy to deploy other environments (as we quickly deploy containerized microservices, there's a process to follow to lock that new env down) - minimal platform => remove unused features/frameworks - sending security directives - like HSTS (HTTP Strict Transport Security - which enforces HTTPS via a response header in the browse)

OWASP Top 10 #8: Software and Data Integrity Failures

- making assumptions related to software updates via CI/CD without verifying integrity of that software - app relies on plugins from untrusted sources/CDN/repos - insecure CI/CD pipeline can introduce potential for malicious code/unauthorized access - apps include auto-update - and updates are downloaded without sufficient integrity verification Ex - router has firmware - and router does not verify whether firmware is signed or not - so attackers can introduce their own firmware - IoT devices - Tv, refrigerator, chromecast - a lot of these devices don't update software through verified sources - SolarWinds attack 2020 - SolarWinds monitoring software used by tons of devices globally. SolarWinds update process was compromised/targeted - as SolarWinds pushes out updates and propagates compromised software to everyone Prevention - use digital signatures to verify software/data is from expected source (checksum , hash algo) - libraries/dependencies are consuming trusted repositories - OWASP dependency check - ensure software supply chain is verified - make sure there's a review process for code and configuration changes - CI/CD pipeline - has proper segregation, proper configuration, and access control - to ensure integrity of code that flows through

OWASP Top 10 #4: Insecure Design

- related to design and architectural flaws that arise from ignore best practices, starting from the planning phase before actual implementation - look at pre-coding activities that are critical for secure design - calls for more threat modeling, reference architecture, and secure Shift Left => moving security considered and testing earlier in the dev process - rather than waiting until end of dev cycle. Integrating security into every stage of SDLC - from design and development - to testing and deployment (improved security, reduced costs, reduced delays, faster time-to-market) - mitigating risks at the design phase is considered a move towards shift left - a secure design could still have a problematic implementation that lead to vulnerabilities - Insecure design prevention starts with a methodology that constantly evaluates threats, code robustly designed and tested, - use threat modeling for critical authentication, access control, biz logic, and key flows thru app. - Write tests to validate critical flows are resistant to threat model. - compile use cases and misuse cases for each Examples of Insecure Design - Movie theater app that sells tickets. Attacker comes in and buys out entire movie theater (without having to put any money down) and blocks out legitimate users/buyers - Building a house with a locked front door, but has an open door in the backyard (doesn't matter how many front door locks you put on)

Top 10

1) Broken Access Control 2) Cryptographic Failures 3) Injection 4) Insecure Design 5) Security Misconfiguration 6) Vulnerable and Outdated Components 7) Identification and Authentication Failures 8) Software and Data Integrity Failures 9) Security Logging and Monitoring Flaws 10) Sever-Side Request Forgery

OWASP Top 10 - #7 - Identification and Authentication Failures/ Broken Authentication

A software vulnerability that is often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question, and account update. This vulnerability helps attackers gain control of the session of the application. Attack Examples Ex => app's session timeouts aren't set properly - allowing hacker to gain access to user info after they have logged out Ex => credential stuffing - a bunch of user/pw stolen from one site and use automated tool to stuff a bunch of user/pw into another site (brute forcing) Ex => automated attacks - try random user/pw stuffing into app Ex => session hijacking Causes: - weak passwords - password reuse - lack of brute-force protection - insecure session on logout/timeout Prevention - implementing MFA - limits on failed login (in case of credential stuffing - using stolen username/pw combo on on site on another site) - password checks (mix of small letters, capitals, special char) - proactively check top 100 passwords - and email users with these pw to force to change - server side session management => there's one session id issued for login, but then another session id for ongoing requests - usually attacker will only have access to initial session id - invalidate session after timeout or logout

OWASP #1: Broken Access control

Access Control - making sure ppl have access to what they're supposed to - and don't have access to what they're not Broken Access Control - when confidential info is viewed by a user who should not have permission to access that data Prevention a) use role-based access control - enforcing RBAC prevents users from accessing unnecessary resources b) least privilege principle (or deny by default) (does a certain role really need SQL delete?) - and give access to minimum amount of time c) ensure access control implemented on server side, on all pages, and API endpoints d) MFA can help authorize the user e) implement proper session management - session timeouts, secure session cookies, revoke on logout. Prevents attackers from manipulating session to gain unauthorized access f) use random 32 char GUID - which make direct object reference much harder (harder than simple iterative/sequential id's) g) log access control failures Types Vertical privilege escalation: An attacker can gain unauthorized access to functionality or data that is only intended for higher-privileged users, such as administrators, by manipulating parameters or session data. Horizontal privilege escalation: An attacker can gain unauthorized access to functionality or data that is intended for other users by manipulating parameters or session data. Direct object reference: An attacker can access and manipulate objects or resources that are not intended for them by manipulating identifiers or parameters. Insecure direct object reference: An attacker can bypass access controls by directly accessing objects or resources that are not intended for them, such as by modifying URLs. Mass assignment - manipulate input fields or params to modify object properties or attributes that a user shouldn't have access to

Cross-Site Request Forgery

An attack that uses the user's Web browser settings to impersonate the user. - user logged into bank and has cookie - user tricked into going to another site with bogus form, they fill out the form and it sends a request to WF for a deposit or withdrawal Prevention - use CSRF token when generating form - only can come from server and server expects that value back when form submitted - SameSite attribute on cookies - limit the scope of cookies to same origin - cookies can only be sent w/ requests to the same domain as the one that set the cookie - HttpOnly cookies - cookies are inaccessible to javascript - referrer header validation => ensure requests originate from expected domain

Broken Authentication - session hijacking, session fixation, session replay attacks

Session Hijacking - stealing an existing valid session cookie - often through sniffing network traffic IE.. MITM attack or just a leaked session ID - once attacker has session cookie - they can gain access to user's session as if they were legit Session Fixation - planting pre-defined session cookie into victim's browser. Once user logs in - the attacker uses the same session cookie that the attacker already knows - thus attacker-owned cookie is authenticated. - requires attacker to have temp access to victim's browser Session Replay Attacks - attacker has access to a session cookie (via fixation or hijacking) - and just reuses the cookie for whatever they want. Or tricking the victim into re-submitting a previously valid request Prevention - use TLS to prevent MTM attacks - set the secure flag on cookies (prevent being submitted over plain-text connection (browsers only send when using https) - set HTTPOnly flag on cookies - so JS doesn't have access to the cookie (can't be hijacked) - regenerate session ID's on every privilege changing action (login, logout, login as admin) - as well as changing on regular short-time intervals (mitigate all 3 of the above attacks with this) - have app reject session cookies that don't match server-side record

OWASP Top 10: #2 Injection

most common types are XSS and SQL Injection SQL Injection - inject malicious SQL code into web app input fields in order to gain unauthorized access to sensitive data store in app db Prevention - any user input is untrusted : - Query parameterization - separate sql statements from any parameters included in call to db - Validate user input (don't allow improper characters) - SQL Limit command (if you were exposed - put limit in place that actually gets sent back from db) - principle of least privilege NoSQL Injection => similar to SQL injection, but with NoSQL there are different set of vulnerabilities because the queries are written in a language that's similar to the code on the backend (IE.. JSON for a mean stack app) . Can be even more serious than SQL injection - operations in mongoose for example are JSON operations - so if you pass a password of '$gt':''" - it just looks in the db for w/e username you want and a password that's greater than 0 chars - same prevention mechanism as SQLi Cross-site Scripting (XSS) - attacker inject malicious JS - Prevention of XSS: - sanitize input, output encoding for all user input - avoid using certain functions w/ user input like eval() or setTimeout - regularly update npm packages and patching Command Injection (shell injection) - execute OS commands on server running app Prevention - - use parameterized commands - restrict input to certain domains - escape user input ( LDAP Injection - attacker modify LDAP statement through similar techniques to SQL injection - resulting in granting of permission to unauthorized queries Prevention => escape special char, parameterize LDAP queries, use custom error pages XPath Injection - when attacker exploits app that builds XPath queries from user input (XML is the language of web services - the data structure of a service and its interface are defined within XML). This is for XML-based web apps Prevention => use parameterized queries, sanitize input and use output encoding