Title: Theory / Unimportant / CS / Descriptive / Web / OWASP

Name: Open web application security project
Definition: a nonprofit foundation that works to improve the security of software.
Page: https://owasp.org/
Abbreviation: OWASP

Name: Top 10 Web Application Security Risks
Definition: Injection
Page: https://owasp.org/www-project-top-ten/
Definition2: Broken authentification
Conjdef: All of
Definition3: Sensitive data exposure
Definition4: XML External Entities
Definition5: Broken access control
Definition6: Security misconfiguration
Definition7: cross-site scripting XSS
Definition8: Insecure deserialization
Definition9: Using components with known vulnerabilities
Definition10: Insufficient logging & monitoring

Name: Injection
Definition: When untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing
unintended commands or accessing data without proper authorization.
Page: https://owasp.org/www-project-top-ten/
Context: OWASP

Name: XML External entity
Definition: Many older or poorly configured XML processors evaluate external entity
references within XML documents. External entities can be used to
disclose internal files using the file URI handler, internal file
shares, internal port scanning, remote code execution, and denial of
service attacks.
Page: https://owasp.org/www-project-top-ten/
Context: OWASP
Abbreviation: XXE

Name: XSS flaw
Definition: whenever an application includes untrusted data in a new web page
without proper validation or escaping, or updates an existing web page
with user-supplied data using a browser API that can create HTML or
JavaScript. XSS allows attackers to execute scripts in the victim’s
browser which can hijack user sessions, deface web sites, or redirect
the user to malicious sites.
Page: https://owasp.org/www-project-top-ten/
Context: OWASP

Question: How to prevent injection
Answer: The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs).
Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().
Page: https://owasp.org/www-project-top-ten/2017/A1_2017-Injection
Answer2: Use positive or “whitelist” server-side input validation. This is not a
complete defense as many applications require special characters, such
as text areas or APIs for mobile applications.
Answer3: For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
Answer4: * Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.

Question: How to prevent broken authentification
Answer: Where possible, implement multi-factor authentication to prevent
automated, credential stuffing, brute force, and stolen credential
re-use attacks.
Page: https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
Answer2: Do not ship or deploy with any default credentials, particularly for admin users.
Answer3: mplement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
Answer4: Align password length, complexity and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies.
Answer5: Ensure registration, credential recovery, and API pathways are hardened
against account enumeration attacks by using the same messages for all
outcomes.
Answer6: Limit or increasingly delay failed login attempts. Log all failures and
alert administrators when credential stuffing, brute force, or other
attacks are detected.
Answer7: Use a server-side, secure, built-in session manager that generates a
new random session ID with high entropy after login. Session IDs should
not be in the URL, be securely stored and invalidated after logout,
idle, and absolute timeouts.

Question: How to preven Sensittive data exposure
Answer: Classify data processed, stored or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
Apply controls as per the classification.
Page: https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
Answer2: Verify independently the effectiveness of configuration and settings.
Answer3: Don’t store sensitive data unnecessarily. Discard it as soon as possible
or use PCI DSS compliant tokenization or even truncation. Data that is
not retained cannot be stolen.
Answer4: Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
Make sure to encrypt all sensitive data at rest.
Answer5: Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
Answer6: Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.
Answer7: Disable caching for response that contain sensitive data.

Question: How to prevent XML External entities
Answer: Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data.
Page: https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
Answer2: Patch or upgrade all XML processors and libraries in use by the
application or on the underlying operating system. Use dependency
checkers. Update SOAP to SOAP 1.2 or higher.
Answer3: Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention’.
Answer4: Implement positive (“whitelisting”) server-side input validation,
filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
Answer5: Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
Answer6: SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations.
Answer7: If these controls are not possible, consider using virtual patching, API
security gateways, or Web Application Firewalls (WAFs) to detect,
monitor, and block XXE attacks.

Question: How to prevent Broken access control
Answer: With the exception of public resources, deny by default.
Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
Page: https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
Answer2: Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage
Answer3: JWT tokens should be invalidated on the server after logout.
Developers and QA staff should include functional access control unit and integration tests.
Answer4: Unique application business limit requirements should be enforced by domain models.
Answer5: Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
Answer6: Log access control failures, alert admins when appropriate (e.g. repeated failures).
Answer7: Rate limit API and controller access to minimize the harm from automated attack tooling.

Question: How to prevent security misconfiguration
Answer: A repeatable hardening process that makes it fast and easy to deploy
another environment that is properly locked down. Development, QA, and
production environments should all be configured identically, with
different credentials used in each environment. This process should be
automated to minimize the effort required to setup a new secure
environment.
Page: https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication
Answer2: A minimal platform without any unnecessary features, components,
documentation, and samples. Remove or do not install unused features and
frameworks.
Answer3: A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see A9:2017-Using Components with Known Vulnerabilities). In particular, review cloud storage permissions (e.g. S3 bucket permissions).
Answer4: A segmented application architecture that provides effective, secure
separation between components or tenants, with segmentation,
containerization, or cloud security groups (ACLs).
Answer5: Sending security directives to clients, e.g. Security Headers.
Answer6: An automated process to verify the effectiveness of the configurations and settings in all environments.

Question: How to prevent Cross-Site scripting
Answer: Using frameworks that automatically escape XSS by design, such as the
latest Ruby on Rails, React JS. Learn the limitations of each
framework’s XSS protection and appropriately handle the use cases which
are not covered.
Page: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)
Answer2: Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet ‘XSS Prevention’ has details on the required data escaping techniques.
Answer3: Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet ‘DOM based XSS Prevention’.
Answer4: Enabling a Content Security Policy (CSP) as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).

Question: How to prevent Insecure deserialization
Answer: The only safe architectural pattern is not to accept serialized objects
from untrusted sources or to use serialization mediums that only permit
primitive data types. If that is not possible, consider one of more of
the following:
Page: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)
Answer2: Implementing integrity checks such as digital signatures on any
serialized objects to prevent hostile object creation or data tampering.
Answer3: Enforcing strict type constraints during deserialization before object
creation as the code typically expects a definable set of classes.
Bypasses to this technique have been demonstrated, so reliance solely on
this is not advisable.
Answer4: Isolating and running code that deserializes in low privilege environments when possible.
Answer5: Log deserialization exceptions and failures, such as where the incoming
type is not the expected type, or the deserialization throws exceptions.
Answer6: Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
Answer7: Monitoring deserialization, alerting if a user deserializes constantly.

Question: How to prevent Using Components with Known Vulnerabilities
Answer: There should be a patch management process in place to:
Page: https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities
Answer2: Remove unused dependencies, unnecessary features, components, files, and documentation.
Answer3: Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use.
Answer4: Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
Answer5: Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue.
Answer6: Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

Question: How to prevent Insufficient Logging & Monitoring
Answer: Ensure all login, access control failures, and server-side input
validation failures can be logged with sufficient user context to
identify suspicious or malicious accounts, and held for sufficient time
to allow delayed forensic analysis.
Page: https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%26Monitoring
Answer2: Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions.
Answer3: Ensure high-value transactions have an audit trail with integrity
controls to prevent tampering or deletion, such as append-only database
tables or similar.
Answer4: Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.
Answer5: Establish or adopt an incident response and recovery plan, such as NIST 800-61 rev 2 or later.
Answer6: There are commercial and open source application protection frameworks such as OWASP AppSensor (old wiki), web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.