-
-
Save ZapDos7/43c7649c01b471e62078ba4868370cc6 to your computer and use it in GitHub Desktop.
-
Don't trust the user - user input to app is prone to errors
-
Validate & Sanitize - cleanup user input in order to prevent XSS and similar issues
-
Limit privileges - using a matrix of actions x roles, make sure user can access the least amount of resources possible & limit their capabilities (might be useful to have multiple log ins per user)
-
Encrypt everything - HTTPS enforces encryption at base layer, ssl certificates can be free and offer the same security as paid ones.
- enforce encryption
- block unencrypted communication
- provide tools to recrypt
Always assume someone is watching all data sent/received.
-
Don't trust yourself - you are prone to forget something or do biased testing. Use both automated (unit) testing alongside human testing (novices alongside pros)
- Public vs Private data
- public data can be accessed by requests (no need to authenticate/authorize), private data can be accessed with an authorized request, require authentication
- all data will be accessed eventually and therefore can be eventually compromised.
- Field Verification - regex, both FE & BE
- Authenticate every interaction - as little information as possible in order to protect their data, but enough to authenticate them (e.g. 2FA)
- Beware leaks in console
- be mindful of logging levels per environment
- use code linter that flags console logs as warnings
- print sensitive data only if required
- delete private data logs immediately
- Assume your walls will be breached
OWASP = Open Web Application Security Project, a non profit organization dedicated to improving the security of web apps & software.
We focus only on REST APIs in this course.
APIs amount for 90% of the data breaches by 2020 because they are rich targets, as they:
- access large amounts of data & info
- can grant elevated privileges
- are the middle man between the app and the resources
- are easy to find
- undergo changes & updates often (e.g. maybe the web app is secure but the mobile version not yet)
- Broken Object Level Authorization
- Broken User Authentication
- Excessive Data Exposure
- Lack of Resources & Rate Limiting
- Broken Function Level Authorization
- Mass Assignment
- Security Misonfiguration
- Injection
- Improper Assets Management
- Insufficient Logging & Monitoring
APIs tend to expose endpoints that handle object identifiers, creating wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using an input from the user.
Broken Object Level Authorization (BOLA) == Insecure Direct Object References (IDORs)
These occur when user-supplied input allows abnormal access (user A uses user B's token in order to access & manage resources user A should not have access to)
How to protect against such attacks?
- We should add authorization checks with user policies & hierarchy
- We should not use user IDs in API requests, instead uses session IDs or tokens
- We should regularly check authorization for clients requesting access
- We should implement a zero-trust model
- We should regularly test
Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users' identities temporarily or permanently. Compromising a system's ability to identify the client/user compromises API security overall.
How can user authentication be implemented poorly?
- Display of sensitive details
- Allowing weak passwords
- Misconfigured tokens
- password reset improperly implemented
- no limit on incorrect attempts
- too few digits in one-time passcode
- no account lookout policy
How to protect against such attacks?
- We should use secure methods to authenticate to APIs
- We should use multifactor authentication & captchas
- We should use temporary access tokens
Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
APIs can expose too much data as they expect the client/user to filter, but that does not account for exposure of sensitive data (e.g. PII = personally identifiable information, PHI = protected health information, user token).
How to protect against such attacks?
- We should filter the data of all API responses, including error messages
- We should limit the exposure of sensitive data/PII
- We should enforce response checks to prevent accidental leaks of data and exceptions
- We should regularly perform checks to search for potentially sensitive information
Quite often APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
Rate limiting = strategy for limiting the amount of data sent in a specific time frame. Without this, attackers can stop an app from functioning or use unlimited amounts of resources to gain access to an application.
How to protect against such attacks?
- We should define proper rate limiting
- We should limit payload sizes
- We should define & enforce resource limits
- We should perform rate-limiting tests
- We should determine appropritae limits & rates
Complex access control policies with different hierarchies, groups and roles, and an unclear separation between administrative and regular functions tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users, resources, and/or administrative functions.
BOLA vs BFLA
BOLA has to do with resource access, whereas BFLA has to do with access to functions of equal or higher privileges (e.g. admins have more actions available to them than a simple user).
How to protect against such attacks?
- We should avoid function-level authorization
- We should deny all access by default
- We should only allow authorized users to access the appropriate groups/roles
- We should perform regular authorization tests
Binding client-provided data to data models without proper properties filtering based on an allow list, usually leads to mass assignment. Either guessing objects' properties, exploring other API endpoints, reading the documentation or providing additional object properties in request payloads allows attackers to modify object properties that they're not supposed to.
e.g. In a request with user info, there is a variable isAdmin, which should not be visible to us, and which we can modify and resend the request, thus granting us administrative level authoriation falsely.
How to protect against such attacks?
- We should disable the mass assignment feature within the framework we're working in
- We should avoid exposing internal variables or object names as input
- We should approve the variables and the objects that the client can update in the API
- We should use an allow list only allowing assignment on certain properties or variables
Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information."
API source code must be regularly srviced to prevent breakdowns. Security Misonfiguration = a broken piece of code which leaves an API vulnerable to attacks.
How to protect against such attacks?
- We should establish and practice hardening and patching procedures. This can be done by creating rules or policies that explain, in detail, how to update and secure your programs and software periodically.
- We should disable any unnecessary applications and features.
- We should also restrict administrative access and practice least privilege
- We should regularly test for security misconfigurations using a combination of scanning tools and manual testing.
Injection flaws, such as SQL, NoSQL, Command Injection, etc, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
The attacker can input malicious commands to the API via file upload, parameters or input fields. These commands can return sensitive information, bypass security checks or take down the app.
Examples:
- Cross-site Scripting (scripts entered into code)
- SQL Injection (SQL DB queries injected into API)
How to protect against such attacks?
- We should perform input validation and proper sanitization for all input and special characters
- We should limit the number of records being returned in queries
- We should use proper filtering to limit the amount of information in the API responses to prevent data leaks
- e.g. by using validated, well documented libraries
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important
We need to protect, disable & make unaccessible older versions of our APIs.
How can this occur?
- Poor inventory/documentation management of API in various environments
How to protect against such attacks?
- We should perform regular security reviews of all of their APIs
- We should keep an up-to-date inventory of all API hosts
- We should limit access to anything that should not be public, like API documentation, - We should retire older and unused versions of the API
- We should create a policy for new API rollouts that includes a checklist of actions you should take prior to flipping the switch (Make sure your policy includes steps to update the API documentation, inventory of what versions are active, and dates that older versions are set to be retired)
- We should add periodic checks to your policy to make sure everything is up to date and have all of it verified and signed off by management.
Insufficient logging and monitoring coupled with missing or ineffective integration with incident response allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract or destroy data.
It takes an average of 277 days for a breach to be discovered (source: IBM, 2022)
Benefits of Logging
- allows event investigation
- helps finding root causes
- reveals whether actions are malicious
Benefits of Monitoring
- detection of normal log ins
- detection of password changes
- detection of account creation
- detection of abnormal API activity
- detection of failed log ins
- detection of unusual character input
- detection of API errors
How to protect against such attacks?
- We should use standard formats to monitor and log all APIs like API gateways, log actions like logins and account creation, log input validation failures, failed authentication attempts, denied access, API errors, and more
- We should avoid sensitive data and logs, keep your log protected like you would protect any sensitive data, monitor your API endpoints across all phases: production, staging, testing, et cetera
- We should react to all security issues identified within your API
- We should perform regular assessments and penetration testing to test your logging and monitoring alerts
- you can remove metadata from files on Windows
- you can also remove it with ExifTool (all OS)
- when full resolution isn't needed, you can take a screenshot of the image in order to also remove its metadata
- obscure information (easy for images - one compact opaque shape, in videos more complex but programs exist)
- symmetric (same key to encrypt & decrypt) & asymmetric (public key to encrypt & private key to decrypt) encryption {plaintext, ciphertext (text through algorithm)}
- Kleopatra
Source: Ασφάλεια του Κυβερνοχώρου στο Οικοσύστημα IoT
- device
- hardware (Can data be encrypted?)
- software (Are there any bugs?)
- communication security (Can someone eavesdrop?)
- command & control (Can an outlier take control?)
"Black Box Testing"
- Identify Vulnerabilities using reverse engineering (!= outcomes) When?
- in the making
- we can find hardcoded credentials
- broken authentication for critical functions (so someone from the outside can alter something)
- device spoofing (using one device you can see what others would see, mimic it to my advantage)
- sensitive user info (e.g. cloud storage)
- firmware problems from 3rd party components
- in an organisation (strong existing configuration)
Pen Testing = test configured infrastructure of existing organisations e.g. 1. the user shut off authentication for a critical function 2. no longer supported security system
How?
- hardware - inspection level
- software
- communications
Skills:
- Debugging
- Analytical Thinking
- Network Engineering Skills
- System Programming
- Reverse Engineering (binary file to code)
- Comm. Skills
- Hardware Debugging Skills
- SDR Skills
Acronyms etc:
- AES
- RSA
- RFID
- ad hoc
- ACL (λίστες ελέγχων προσώπων)
- RBAC (ρόλοι χρηστών για έλεγχο access)
Also check:
Source: Fosscomm 2017 Tor Presentation
- TOR hides your IP
- If we had only one relay box (nodes/relays), then it's easier to hack. TOR = many juristictions ("boxes") therefore harder to hack
- Also TOR offers encryption (each relay has its own key) => few layers leave at a time (like an onion!)
- These additional hidden relays act like bridges for censorship (offering freedom to the users)
- Anonymus client & server (mysite.onion) - also used to give shit to e.g. wikileaks
- Self authenticated
- End to end encryption
- Built in NAT punching
- Limit surface area
- No need to "exit" TOR
Also check: