Security 101

CPSC455 - Lab 4.1

Agenda

• Overview
• OWASP
• Security Triad
• Deep Dive into 3 Types of Security Risks
• Broken Authentication
• Cross-Site Scripting (XSS)
• SQL Injection

OWASP

OWASP - Open Web Application Security Project

​

• Non-profit Community
• Education + Training
• Tools + Resources

​

“The OWASP Foundation works to improve the security of software through its community-led open source software projects, hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.”

(There’s a LOT of information there, and while you don’t have to be an expert in security, it’s good to know how to find the information when you need it.)

OWASP

Top 10 Web Application Security Risks

https://owasp.org/www-project-top-ten/

1. Injection 6. Security Misconfiguration
2. Broken Authentication 7. Cross-Site Scripting (XSS)
3. Sensitive Data Exposure 8. Insecure Deserialization
4. XML External Entities (XEE) 9. Using Components with Known Vulnerabilities
5. Broken Access Control 10. Insufficient Logging and Monitoring

Security Triad

Confidentiality

Availability

Integrity

CIA

Security is about protecting these Confidentiality, Integrity and Availability.

​

We can understand security vulnerabilities by their impact on these factors.

Security Triad

Confidentiality

Availability

Integrity

CIA

Confidentiality - Attacker could gain access to sensitive data that they shouldn’t have access to

​

Integrity - Attacker could modify or delete sensitive data that they shouldn’t have access to

​

Availability - Attacker could prevent legitimate users from accessing the site or their data

​

​

Can you think of examples?

Security Triad

Confidentiality

Availability

Integrity

CIA

Ex 1. You enter in a wrong password 50x, so the site locks out any logins for 2 hours.

​

Ex 2. A vulnerability that exposes the session key, allowing you to masquerade as a different user.

​

Ex. 3. You find a SQL injection flaw that allows you to ADD records to a Table containing students’ grades

Broken Authentication

Broken Authentication

Weaknesses in the Application:

• 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.
• Puts the password in a query string parameter. (Always send the password in the body of a POST request.)

Broken Authentication

Brute-force attacks can be used to attempt to log in by trying many combinations of credentials.

• Most important protection against brute-force attacks is a strong password
• Rules like "must be 12 characters long and contain numbers, letters, and punctuation" can also help improve password quality.
• CAPTCHA can be effective at preventing brute-force attacks.
• Doesn’t have to be present on every login, but only if there is suspicious activity.

Broken Authentication

Bad practices:

• Letting the user know what failed
• Ex. “Invalid password” or “Username does not exist”
• Locking users out
• It does slow down a brute-force attack, but prevents legitimate users from logging in

Broken Authentication

Also have to consider:

• Multi-factor authentication
• Salting and hashing passwords in storage
• Forgotten/changing passwords
• Lots more!!

Broken Authentication

Final takeaway:

​

Just say no to building authentication systems. Use a well-established authentication system.

​

Cross-Site Scripting (XSS)

XSS

• One of the most common and dangerous vulnerabilities
• 2nd most prevalent in the OWASP Top Ten
• Estimated that 2/3rds of all websites have XSS vulnerabilities
• Attackers inject malicious client-side scripts into web pages viewed by other users
• 3 Types - Reflected, Stored, DOM

XSS

How does it happen?

• Attacker can use XSS to send a malicious script to an unsuspecting user
• End user’s browser has no way to know that the script should not be trusted, and will execute the attacker’s script.
• Malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site

XSS

Reflected

• Account for approximately 75% of the XSS vulnerabilities that exist in the real world.
• Untrusted data in the request is echoed by the server back into the response without properly encoding it or sanitizing it.
• The application or API includes unvalidated and unescaped user input as part of HTML output.

​

​

XSS

DOM-based

• DOM-Based XSS vulnerabilities are very similar to Reflected XSS Vulnerabilities, except that the vulnerable code is implemented in the site's client-side JavaScript rather than on a server.
• The vulnerable code reads untrusted data and inserts it into the DOM
• The important distinction from Reflected is where the vulnerability exists, not where the data comes from

XSS

Stored

• Often considered a high or critical risk
• Attacker's malicious code may not be immediately reflected into the response, but is stored by the vulnerable application and executed in users' browsers on future responses
• Malicious code may be stored in a server-side database or in client-side browser storage.
• More dangerous than Reflected XSS because an attacker doesn't have to interact with a victim to exploit the vulnerability

​

​

XSS

Quick Example - https://github.com/danyakarras/XSS_Example

• Let’s make a blog post with:
• <button onClick=alert("give&nbsp;me&nbsp;your&nbsp;password")> click here </button>
• innerHTML is ALWAYS a bad idea
• Which version of XSS is this?
• Go check your assignment 1! (No, we didn’t take marks off.)
• If you really want to use innerHtml: https://gomakethings.com/how-to-sanitize-third-party-content-with-vanilla-js-to-prevent-cross-site-scripting-xss-attacks/

​

​

XSS

How to prevent:

• Use 3rd party frameworks such as the latest Ruby on Rails, React JS that automatically escape XSS by design
• React tries to stop you: https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
• Escape HTML yourself
• Actually lots of rules here: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

XSS

Other Examples:

• https://owasp.org/www-community/attacks/xss/
• https://pentest-tools.com/blog/xss-attacks-practical-scenarios/

​

​

SQL/NoSQL Injection

SQL Injection

SQL Injection is among the most dangerous types of vulnerabilities because it can give an attacker direct control over the application's data.

Attacker could:

• Drop a table
• Modify permissions
• Read data
• Learn more about the DB structure to create more advanced attacks such as a worm

​

SQL Injection

SQL Injection vulnerability is a bug that occurs in application code that uses input data to write SQL code, and it causes the input data to be mistakenly interpreted as SQL code itself.

Ex. SELECT * FROM Books WHERE title = ‘{user_input}’;

Attacker could set user_input to be:

“Harry Potter”; DROP DB;

SQL Injection

An application is vulnerable to attack when:

• User-supplied data is not validated, filtered, or sanitized by the application
• Hostile data is directly used or concatenated, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures

SQL Injection

How to prevent:

• 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)
• Use positive or “whitelist” server-side input validation. (Don’t allow special characters)
• Escape special characters using the specific escape syntax for that interpreter
• SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous (Ex. SELECT * from {tableName})

NoSQL Injection

• MongoDB deliberately allows applications to run JavaScript on the server within the $where and mapReduce operations
• The documentation is very clear that if this functionality is used, the developer should take care to prevent users from submitting malicious JavaScript
• MongoDB deliberately includes a potential injection vector
• As is often the case in web application security, the best way to prevent NoSQL injection attacks is to avoid using unsanitized user inputs in application code, especially when building database queries.

https://www.netsparker.com/blog/web-security/what-is-nosql-injection/

SQL/NoSQL Injection

Code that writes code is ALWAYS a bad idea!

(but sometimes necessary)

TRY HACKING

HACK THE BOX�(they’ve changed it from a year ago, so this might not work now :’( )

1. Go here: https://www.hackthebox.eu/
2. Click “Join now”
3. Register
4. Open your console :)

TRY HACKING

OWASP Juice Shop

https://owasp.org/www-project-juice-shop/

“The application contains a vast number of hacking challenges of varying difficulty where the user is supposed to exploit the underlying vulnerabilities. The hacking progress is tracked on a score board. Finding this score board is actually one of the (easy) challenges!”

Resources

Best Stack overflow post ever?

• https://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication

​

Preventing NoSQL Injection in MongoDB:

• https://lockmedown.com/securing-node-js-mongodb-security-injection-attacks/
• https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection

​

More on XSS

• https://excess-xss.com/