Software and Hardware Development Security

Activity 9.1 Review an Application Using the OWASP Application Security Architecture Cheat Sheet

In this excercise I will download BurpSuite and scan a sample site. MORE SCANNING!

Part 1: Download and Installation

Burpsuite provides a free community edition. Their scanner can be downloaded from here

https://subgraph.com/vega/

OWASP maintains an excellent list of scanning utilities: https://owasp.org/www-community/Vulnerability_Scanning_Tools

Part 2: Select an application and scan it

As Burpsuite is a dedicated web application scanner… I need a web application to scan. Obviously running around the world wide web scanning is not legal. However many organisations run intentionally vulnerable web applications for cyber security practice purposes. Here is a short list of some of these vulnerable sites:

http://www.google-gruyere.appspot.com/ A vulnerable web app provided by Google. Clicking start generates a unique ID, creating a personal website for your to hack away at.

http://www.itsecgames.com/ Purposedly buggy web applicaiton. Available as stand-alone code or a VM.

http://damnvulnerableiosapp.com/ A vulnerable IOS application.

https://github.com/webpwnized/mutillidae) A vulnerable web app created by OWASP.

https://owasp.org/www-project-webgoat/ Webgoat! An insecure Java application maintained by OWASP.Available as a handy docker container.

https://dvwa.co.uk/ Damn vulnerable web application. A PHP/MysQL vulnerable web application for testing.

For this example I will start with Google’s Gruyere. It is very easy to get started: since it requires no local installation or setting up a VM. Simply visit the site and click start to get going.

Scanning steps:

1. Start up Burpsuite. Select > New Scan This performs an end-to-end managed scan.

2. On the scan type page, I will enter the gruyere URL and leave “crawl and audit” selected. Also, I will leave “Scan using HTTP & HTTPS” selected to scan across both protocols. Click OK to start the scan.

3. Grab some popcorn.

4. As the scan progresses, discovered vulnerabilities will appear in the Issue Activity section. Clicking them will reveal more details about the issues found.

5. Once the scan completes, detailed info of specific vulnerabilities can be found in the Target tab.

6. In order to generate a report, select indvidual issues or select all and right click > Report Selected Issues.

7. You can then generate a fancy html report as ouput. As I chose to generate a report from all the issues, my report has length of over a hundred pages. Selecting the vulnerabilities to include in the report will result in a shorter length.

Part 3: Analyze the scan results

Cross Site Scripting

Definition: The scan identified 6 confirmed issues of reflected cross site scripting with a severity of high. A reflected cross site scripting attack is when data is copied from a request and echoed into an application’s immediate response. This attack can allow an attacker to execute Javascript code suppllied by the attacker within the user’s browser. The code can provide actions such as stealing user credentials, logging key strokes and so on.

Remediation:

1. Input Validataion. For example, a field request a year should accept only numbers and exactly four digits
2. User input should be HTML encoded when it is copied into a response. For example, HTML metacharacters such as <> and = should not be included in a response.

Issue Breakdown:

• Note the higlighted section showing how the request is sent and the response delivered.

Clear Text Submission of Password

Definition: The scan confirmed 2 vulnerable issues of passwords being submitted in cleartext. Passwords are currently transmitted over unencrypted connections. This makes them vulnerable to interception by an attacker.

Remediation:

1. Applications should use the latest version of TLS, Transport Level Encryption, enabling HTTPS. This ensures all communications between a client and server are encrypted. Nearly all modern web applications use HTTPS and web browsers will frequently display a warning to a user before allowing them to communication with an application using HTTP.

Issue Breakdown:

• Note the highlighted section in the response showing the password returned in cleartext. This response could easily be captured by an attacker.

Password submitted using GET method

Definition: The scan confirmed 2 vulnerable issues of GET methods being used to submit passwords. This vulnerability is a low severity. Using a GET method, passwords are transmitted within the query string of the requested URL. The password can then be logged by reverse proxies, displayed on screen or even revealed to a thirdy party via a refferer header when a user clicks on an off-site link.

Remediation:

1. Forms submitting passwords should use the POST method. The application code may need to be refactored to specify the method attribute of the FORM tag as method=”POST”

Issue Breakdown:

Frameable response (potential Clickjacking)

Definition: Five potential clicking issuers were detected. If a page does not set a proper X-Frame-Options or Content-Security-Policy HTTP header, an attacker could load an iframe within the page. This could enable a click jacking attack. A clickjacking attack is when an attacker overlays fake page or interface over the normal page. The user will then unknowingly click or perform keystrokes on the page, performing unintended actions or revealing credentials.

Remediation: The application can return a response header with the name X-Frame-Options and a value of DENY to prevent all forms of framing. Alternatively the value SAMEORIGIN can be set to allow framing only by pages on the same origin as the response itself.

Issue Breakdown:

Activity 9.2 Learn About Web Application Exploits from WebGoat

Part 1: Download Docker

As mentioned above, Web Goat is a purposedly vulnerable Java web application maintained by OWASP. I will run Web Goat in a docker container on my Kali Linux VM. First, lets download and install docker. I will follow the official instructions located here: Docker

As per the below instructions, the commands needed to install docker are: kali@kali:~$ sudo apt update kali@kali:~$ sudo apt install -y docker.io kali@kali:~$ sudo systemctl enable docker --now kali@kali:~$ docker

In order to start Web Goat, we will use the all-in-one docker container. All the necessarry files can be downloaded from Github: https://github.com/WebGoat/WebGoat

1. Clone into the Repositiory:

2. Navigate to Web Goat > Docker or alternatively run “https://hub.docker.com/r/webgoat/goatandwolf”

3. Run the docker commands to run the container. Be sure to set your timezone appropriately. docker run -p 8080:8080 -p 9090:9090 -e TZ=Europe/Amsterdam webgoat/goatandwolf

4. Open your browser. WebGoat will be located at: http://127.0.0.1:8080/WebGoat and WebWolf will be located at: http://127.0.0.1:9090/WebWolf .

5. There are serveral lessons in Web Goat. I will skip the first few lessons and go through the section on SQL injection.

Part 2: SQL Injection

Definition: SQL injection is inserting SQL commands into forms and other exposed areas of a web application to elicit a response from the web application’s underlying database. This can result in displaying information, which is not intended to be displayed, modifying the database, shutting down the database, adding privileges to the database and compromising database integrity.

Lesson 2 in Web Goat provides the most basic example of an SQL injection, which results in dumping employee information.

SQL injection involves inserting DML, “Data Maniuplation Language” commands into inputs of a web application.

Core DML commands are:

• SELECT retrieves data
• INSERT adds data to a table
• UPDATE updates data in a a table
• DELETE Delete all records in a table

As lesson 3 in Web Goat demonstrates, SQL injection can violate both confindentiality and integrity. Here we are able to both reveal confidential employee info and change it with a DML command.

SQL injection commands can also leverage DDL, “Data Definition Language” commands. These commands can change the structure of the database, violating data integrity.

Core DDL commands are:

• CREATE create a database and/or related objects
• ALTER change the database structure
• DROP delete objects from the database

In Lesson 4, we modify the table schema by adding an additional column to the database.

DCL, “Data Control Language” is used to manage priveleges. An attacker using DCL can grant themselves unwanted priveleges to the datbase.

Core DCL commands are:

• GRANT allow user access to a table
• REVOKE remove user access

Here is an example in the Web Goat excercises of granting the right to alter tables:

SQL Injection can be remediated through input validation, i.e. checking that user supplied input is not an SQL command. Without proper input validation, crafted statments such as this can result in dumping all the users in a database:

As ‘1’ = ‘1’ always evaluates to true this will result in data being dumped from the table. The next two excercises provide further examples of this:

Query chaining allows you to append one or more queries to the end of an actual query by using the “;”. This function allows for ever further mischief… In the next Web Goat Excercise, you can chain the following query: '; UPDATE employees SET salary = 10000000 WHERE auth_tan = '3SL99A This query attaches to the underlying query of the web application, allowing you to adjust the salary of anyone in the database.

The last example of Web Goat provides an example of deleting an access log table to cover your tracks. This example also leverages query chainging. Inserting the following query will delete the log table completely. '; DROP TABLE access_log --

Glossary

A glossary of all the terms, acronyms and slang I run across for this chapter.

SDLC	Software Development Lifecycle
Feasibility Phase	Initial investigation to determine whether development should begin. Review existing and available alternatives.
Analysis and requirements definition phase	Customer input is used to determine the desire functionality; functions are prioritised.
Design phase	Phase where architecture, functionality, integration, techniques, workflows, etc are considered
Development phase	The phase where coding happens
Testing and Integration phase	Formal testing phase with customers or other outside of the development team
Training and transition phase	Also called the acceptance, installation and deployment phase - ensures end users are training in the software usage
Operation and maintenance phase	Phase where patching, updating and maintenance occurs.
Disposition phase	The EOL, when the software is disposed of
Software environments	Development, test and production envs
Waterfall	SDLC method where each phase is followed by the next. Relatively inflexible, but used for complex applications
Spiral	Uses the linear development concepts from waterfall but adds iterative processes that revisits phases several times; strong emphasis on risk management and review
Spiral Development Phases	Requirements Gathering > Design > Build >Evaluation
Agile	SDLC which uses an iterative and incremental process rather than a linear process;
Sprint	Short working session in Agile
Backlogs	Lists of features needed to complete a project
Planning Poker	Game used to estimate the cost of a project in Agile
Timeboxing	Previously agreed upon time amount for person to work on a goal
User stories	Stories which are collected to describe high-level user requirements
Velocity Tracking	Adds up the estimates of the current sprints effort and then compares it to what was completed
RAD	Rapid Application Development SDLC Iterative process that focuses on building prototypes
RAD phases	Business Modelling > Data Modelling > Process Modelling > Application Generation > Testing and Turnover
Big Bang	SDLC which relies on no planning process - focuses on starting code and determining requirements as the project progresses
V Model	SDLC which pairs a testing phase with every development phase
DevOps	Combines software development and IT operations with the goal of optimizing the SDLC - uses a collection of tools called toolchains
Develops	Integrates security into DevOps where security is a shared responsibility at each stage of development
CI	Continuous Integration - Check code into a repo often
CD	Continuous Deployment - Rolls out changes into production as soon as they are committed
Improper Error Handling	Results in an error message being dumped to the screen - possibly revealing exploitable info
Dereferencing	Occurs when a pointer has a null reference value - often leads to a crash caused by an error handler
Insecure Object References	When an app exposes info about internal objects and the backend storage system
Race Conditions	Allows possible exploits of timing and execution in an application
Insecure Components	Occurs when a component of an application or service is vulnerable
Insufficient Logging and Monitoring	Error which results in being unable to determine what went wrong, etc.
Weak Default Configurations	When standard configs are weak - like using a default db. password
strcpy	Insecure function which allows for buffer overflow attacks
Firmware	Embedded software used by a device. Not all devices are configured to update their firmware. Vulnerable to attack.
Embedded Systems	Computer systems part of a larger system; smaller lightweight operating systems; less attack surface but more vulnerable.
Secure coding best practices	Have a secure coding policy, do risk assessments, perform input validation, check and perform output encoding, setup a WAF, manage error messages, Consider database security, use parameterized queries, secure sensitive info, build for HA, use MFA, monitor and log, secure network traffic, perform cookie management
OWASP Top Application Controls	Define Security Requirements, Leverage Frameworks, Secure DB, Encode and Escape Data, Validate All Inputs, Implement Digital Identity, Enforce Access Controls, Protect Data Everywhere, Log and Monitor, Handle Errors and Exceptions
Insecure Interaction Between Components	Includes issues such as SQL injection, file upload problems, cross site request forgery, cross site scripting
Risky Resource Management	Deal with buffer overflows, path traversal attacks and ways software fails to guard resources
Porous Defences	Permissive rights, hard-coded credentials, missing auth and authorization, unsalted hashes
Salting	adding random data to the input of a�hash�function to guarantee a unique output
API	Middleman system between clients and servers - Define how the client should ask for info and how the server show respond - allows programs written in any language to use the API
SOA	Service Oriented Architecture - provides services to components of a system via network protocols
REST	Replacement for SOAP - Flexible and allows developers to create their own APIs
SOAP	Simple Object Access Protocol web services protocol
Pair programming	Agile technique where one developer writes the code and the other reviews it as they write
Over the shoulder	Code review technique where the developer explains how the code works to another dev
Pass Around Review	Code review technique where completed code is sent around to developers for a review
Tool-assisted review	Code review via software-based tools and automation
Fagan Inspection	Form of structured code review intended to find problems during the development process
Fagan Inspection Process	Planning > Overview > Preparation > Meeting > Rework > Follow-up
Static Code Analysis	Analysing code for problems by reviewing it without actually running it
Dynamic Code Analysis	Providing inputs to code and running it; Often done with automated testing
Fuzzing	Testing which involves sending random or invalid data to an application in order to test it. Can detect input validation and memory issues.
Mutation Testing	Creating mutant variants of the code with small changes and testing these variants
Load Testing	Simulates full application load
Stress Testing	Simulates beyond normal application load
Security Regression Testing	Testing code after a change or update to ensure now new vulnerabilities have been introduced
User Acceptance Testing	When users are asked to validate if an application meets business and user requirements.
Interception Proxies	Capture information between a browser and a web service
Hardware Root of Trust	Refers to the cryptographic keys which secure the boot process - meaning the system trusts the hardware
TPM	Trusted Platform Module, provides Remote Attestation, Binding aka encryption and Sealing which sets decryption requirements
Measured Boot	Measures each component from the firmware to boot drivers - looking for any security issues - these logs can be sent to an admin.
Secure Processing	The processing and execution environment is secure
Atomic Execution	When a process both reads and writes a location during the same operation - prevents other processors from reading or writing or tampering during an operation
Secure Enclaves	Hardware components which provide cryptographic operations and user authentication, designed to remain secure even if the OS is compromised
Self-encrypting devices	Devices with built in encryption which require a key for read and writes
Bus encryption	Protects data traveling inside a system, securing data as it flows from one computer component to another