CH12 Secure Programming Flashcards
OWASP Top Ten Vulnerabilities 2021
A01 Broken Access Control
A02 Cryptographic Failures
A03 Injection
A04 Insecure Design
A05 Security Misconfiguration
A06 Vulnerable and Outdated Components
A07 Identification and Authentication Failures
A08 Software and Data Integrity Failures
A09 Security Logging and Monitoring Failures
A10 Server-Side Request Forgery
A01 Broken Access Control (BAC)
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorised information disclosure, modification, or destruction of all data or performing a business function aoutside the users limits
Includes CWE 22 Path Traversal
Input from untrusted sources is used, without further checking, as part of a file system path.
Command injections can result in data loss and unauthorised access
A01 BAC: Hard-coded credentials
Many software ships with hard-coded credentials, or secrets
Reasons for shipping hard-coded credentials or secrets (e.g. cryptographic keys, passwords) include:
- the need for accessing 3rd-party/external systems requiring authentication
- making the end-user configuration easier
- left-over debug code
It’s a common issue, and seldom intentional. It is a backdoor.
A02 Cryptographic Failures
- Is any data transferred in clear text? Verify all internet traffic e.g. between load balancers, web servers, or back-end systems
- Are any old or weak cryptographic algorithms or protocols used either by default or in older code
- Is the received server certificate and the trust chain properly validated
^ Just a few questions
Causes
- Insecure Random Generator
- Use of deprecated algorithms, protocols, or key lengths
- Not using encyrption where its supposed to be used
- Not or wrongly validating certificate
- Weak secrets
A03 Injection
Occurs 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
CWE 89 SQLi (SQL injection)
Input from untrusted sources is used without further checking as part of a database query/SQL expression
affects python, java, ruby, php, c#, sql
sql injections can result in data loss, unauthorised access, data manipulation and access
Secure programming recommendations for Injection (SQL/XSS)
Use of a Prepared statement/parameterized queries, treating input data as purely text and not as an SQL command
Using well sanitized libraries (don’t write your own)
Templating engines
CWE 79 Cross-Site Scripting (XSS)
when 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 scirpts in the victim’s browser which can hijack user sessions, deface websites, or redirect the user to malicious sites
(XSS) Problem: user input is directly displayed in an output web page, without any sanitation. The typical attack pattern is:
- The attacker identifies a website with XSS vulnerabilities
- The attacker creates a URL that submits malicious input (e.g., including malicious links or JavaScript code) to the attacked website
- The attacker tries to induce the victim to click on the URL (e.g., by including the link in an email)
- The victim clicks the URL, hence submitting malicious input to the attacked website
- The website response page includes malicious links or malicious JavaScript code (executed on the victim’s browser
Vulnerable code: Python
from flask import Flask, request, make_response, escape
app = Flask(__name__)
@app.route(‘/foo’)
def unsafe():
first_name = request.args.get(‘name’, ‘’)
return make_response(“Your name is “ + first_name)
Flask provides a templating engine (Jinja2) which provides some protecton:
Python
def safe():
first_name = request.args.get(‘name’, ‘’)
return render_tempate(“name”)
Jinja2: name.html
Your name is
{{first_name}}
Where is the vulnerable component in this code and how can it be fixed?
PYTHON
import pymysql
con = pymysql.connect(‘localhost’, ‘user17’, ‘s$cret’, ‘testdb’)
myid = user_input() # untrustworthy input
with con:
cur = con. cursor()
cur.execute(“SELECT * FROM cities WHERE id=” + myid)
cid, name, population = cur.fetchone()
print(cid, name, population)
cur.execute(“SELECT * FROM cities WEHRE id=” + myid)
instead use
cur.execute(“SELECT * FROM cities WHERE id=%s”, myid)
3 main types of XSS
Reflected XSS
Stored/Persistent XSS
DOM XSS
Reflected XSS
The server reads data directly from the HTTP request and reflects it back in the HTTP response
Stored/Persistent XSS
The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a (potentially much) later time, the dangerous data is subsequently read back into the application and included in the dynamic content
As it is stored in the data store of the server, it is likely that all users of the server will interact with or will at least see the malicious payload, making Persistent XSS the most dangerous XSS
Client-Side DOM-Based XSS
the client performs the XSS injection into the page
allows for the manipulation of the Document Object Model (DOM) of other users
Why is XSS protection so hard
there are many vectors in JS that XSS can be injected
there are many character encodings
Protection is framework specific and there are many frameworks
Not all browsers behave the same
What is a Content Security Policy (CSP)
a security policy that a server sends to the client (web browser) and that should, at runtime, enforced by the web browser. It can act as an added layer of security helping to detect and mitigate certain kinds of attacks such as XSS
CSPs can control
The origin of resources
CSP
default-src ‘self’ cdn.example.com;
Or, more fine-grained, only scripts, images, etc.
By default, forbids eval
enables sandboxes for requested resources
A04 Insecure Design
a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation.
Looks at
Requirements and resource managament
secure design
SDLC
A05 Security Misconfiguration
The application might be vulnerable if the application is:
Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services. Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges). Default accounts and their passwords are still enabled and unchanged. Error handling reveals stack traces or other overly informative error messages to users. For upgraded systems, the latest security features are disabled or not configured securely. The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values. The server does not send security headers or directives, or they are not set to secure values.
Without a concerted, repeatable application security configuration process, systems are at a higher risk.
A06 Vulnerable and Outdated Components
You are likely vulnerable:
If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies. If the software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries. If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use. If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, leaving organizations open to days or months of unnecessary exposure to fixed vulnerabilities. If software developers do not test the compatibility of updated, upgraded, or patched libraries.
A07 Identification and Authentication Failures
Confirmation of the user’s identity, authentication, and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:
Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. Permits brute force or other automated attacks. Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin". Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers," which cannot be made safe. Uses plain text, encrypted, or weakly hashed passwords data stores
A08 Software and Data Integrity Failures
relate to code and infrastructure that does not protect against integrity violations.
An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise
A09 Security Logging and Monitoring Failures
Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs any time:
Auditable events, such as logins, failed logins, and high-value transactions, are not logged. Warnings and errors generate no, inadequate, or unclear log messages. Logs of applications and APIs are not monitored for suspicious activity. Logs are only stored locally.
A10 Server Side Request Forgery
a web security vulnerability allowing attackers to force server-side applications to make requests to an unintended location
all systems accepting web requests are potentially vulnerable
SSRF can result in unauthorized acccess, data loss, command injections
SSRF Prevention
Can happen on:
the Network Layer
- Network segmentation
- Use a “deny by default” firewall policy
Application layer:
- Strict sanitization and validation of user input
- strict allow-listing of URLs in the application layer
- Do not send raw responses from back-end system to clients
- Disable HTTP redirection