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
