Don’t Be A Dummy
Secure Your[self,company,site]
Matt Johnson
Who am I?
Who am I?
My name is Matt Johnson
I enjoy hiking and rock climbing with my wife
My wife Chelsea and I have been married for a little over a year
My wife and I are also musicians and we both currently play in a band with Madison Vandenburg, second runner up on American Idol 2019
Who am I?
I have always just wanted to figure out how things work and to understand them, and then I want to know what else they’re capable of
Since I was a teenager, I was fascinated by cyber security and “hacking culture” in general.
In college, those interests progressed and I majored in Computer Science and specialized in cyber security
I was the president of the Cyber Defense club, and we competed nationally in cyber security challenges, both as red team and as blue team
Who am I?
Developer at Packet Tide - We own EEHarbor*
I personally have worked on upgrading most of the add-ons we own to ExpressionEngine 5 alongside Jace
We currently offer a service upgrading ExpressionEngine websites to latest version of EE5, and this is how I spend most of my time right now.
We’ve seen it all.
*(Not EE Harbor, not EEHarbour, not EE-Harbor)
The way sites were built 10 years ago is not the way you should be building sites now.
Should you really care about this? Yes.
Invest in your education
Set aside time to learn
There are a ton of inexpensive and free resources
Read through OWASP Top 10
Go through Gruyere exercises
Read OWASP cheatsheets
My Goals
Broader understanding of attack vectors
Learn how to make more secure websites
I hope some of my examples shock you into actually doing it
OWASP
OWASP
Open Web Application Security Project
owasp.org
OWASP Top 10
A1:2017-Injection
A2:2017-Broken Authentication
A3:2017-Sensitive Data Exposure
A4:2017-XML External Entities (XXE)
A5:2017-Broken Access Control
A6:2017-Security Misconfiguration
A7:2017-Cross-Site Scripting (XSS)
A8:2017-Insecure Deserialization
A9:2017-Using Components with Known Vulnerabilities
A10:2017-Insufficient Logging&Monitoring
Running Old Versions of Software
Running Old Versions of Software
CVEDetails (cvedetails.com)
Exploit DB (exploit-db.com)
This data is taken from the National Vulnerability Database (nvd.nist.gov)
As of Monday, Sept 30, there are 121,994 vulnerabilities listed.
Number of known vulnerabilities by Product
Apache: 1203
Nginx: 26
MySQL: 255
iOS: 1655
Mac OS X: 2212
ExpressionEngine: 4
Laravel: 5
CraftCMS: 10
Wordpress: 298
PHP: 602
All numbers from cvedetails.com
Patch your old software!
Cross Site Scripting (XSS)
Cross Site Scripting (XSS)
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
Source: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
XSS: File Upload
A file containing a malicious script is uploaded to a vulnerable site
Anyone who views this file can be affected
Anywhere a user can upload files should set off a red flag
File Upload XSS: Does this happen?
XSS in Slack gist integration -
Create a gist called: "><svg onload=alert(1)>
have gist integration enabled and put a link in a slack chat
Visit the 'raw' or 'new window' pages for this gist, for example: https://outpost.slack.com/files/zemnmez/F029MDY33/___svg_onload_alert_1__
Stored XSS
Script is stored on the server somewhere
This could be the database, message forum, comments,
Stored XSS: Does this happen?
Bypass for #488147 enables stored XSS on https://paypal.com/signin again https://hackerone.com/reports/510152
Due to a configuration in frontend, caching servers, it was possible for a researcher to use request smuggling to convert a page request into a cached redirect. If the cached redirect were accessed by a legitimate user, an attacker's content would be rendered instead of the requested page. While this would not impact any back-end data, this could interfere with the integrity of certain pages, including potential interference with the sign-in page. PayPal worked with the researcher and our technical teams to remediate the issue and confirm there was no evidence of real-world attacks.
Reflected XSS
Occurs when executable code is injected in an HTTP response
The injected script is not stored on the server, but instead impacts users who are lured into opening a malicious link.
Reflected XSS: Does this happen?
Reflected XSS on developer.uber.com via Angular template injection
https://hackerone.com/reports/125027
So a hacker can trigger a javascript alert...
Who cares? ™
How do we defend against it??
XSS Prevention
Escape and sanitize all the things!
Never trust the end user
Escape everything
Restrict the type of file that can be uploaded. Whitelisting filters, limits on file-size, and validating file content are also effective methods.
Never trust the end user
OWASP Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
Never Insert Untrusted Data Except in Allowed Locations
Directly in a script:
<script>...NEVER PUT UNTRUSTED DATA HERE...</script>
Inside an HTML comment:
<!--...NEVER PUT UNTRUSTED DATA HERE...-->
Never Insert Untrusted Data Except in Allowed Locations
In an attribute name:
<div ...NEVER PUT UNTRUSTED DATA HERE...=test />
In a tag name:
<NEVER PUT UNTRUSTED DATA HERE... href="/test" />
Never Insert Untrusted Data Except in Allowed Locations
Directly in CSS:
<style>
...NEVER PUT UNTRUSTED DATA HERE...
</style>
Client State Manipulation
Client State Manipulation
SQL Injection
SQL Injection
SQL injection is a technique that uses code injection to attack database type applications. Malicious SQL queries are inserted via input from the client to the application. Successful attacks of this type can result in:
<form method="post" action="login.php" enctype="multipart/form-data" >
Username:<input type="text" name="Username" id="Username"/></br>
Password:<input type="text" name="Password" id="Password"/></br>
<input type="submit" name="submit" value="Submit" />
</form>
<?php
$username = $_POST['Username'];
$password = $_POST['Password'];
$server = "MyServer\sqlexpress";
$options = array("Database"=>"ExampleDB", "UID"=>"MyUID", "PWD"=>"MyPWD");
$conn = sqlsrv_connect($server, $options);
$sql = "SELECT * FROM UserTbl WHERE Username = '$username' and Password = '$password'";
$stmt = sqlsrv_query($conn, $sql);
if(sqlsrv_has_rows($stmt)) {
echo "Welcome.";
} else {
echo "Invalid password.";
}
?>
<?php
$username = $_POST['Username'];
$password = $_POST['Password'];
$server = "MyServer\sqlexpress";
$options = array("Database"=>"ExampleDB", "UID"=>"MyUID", "PWD"=>"MyPWD");
$conn = sqlsrv_connect($server, $options);
$sql = "SELECT * FROM UserTbl WHERE Username = '$username' and Password = '$password'";
$stmt = sqlsrv_query($conn, $sql);
if(sqlsrv_has_rows($stmt)) {
echo "Welcome.";
} else {
echo "Invalid password.";
}
?>
$sql = "SELECT * FROM UserTbl WHERE Username = '$username' and Password = '$password'";
What happens if $password equals:
' or 1 = 1--
SELECT * FROM UserTbl
WHERE Username = 'admin'
and Password = '' or 1 = 1--'
SQL Injection
Source xkcd.com
Preventing SQL Injection
Prepared statements
Bind variables
Whitelisting
Use a framework ( ee()->db-> ) Most frameworks are going to automatically sanitize your inputs for you.
Cross Site Request Forgery (CSRF or XSRF)
Cross Site Request Forgery
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.
Passwords
Denial of Service (DoS)
Denial of Service (DoS)
The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others. If a service receives a very large number of requests, it may cease to be available to legitimate users. In the same way, a service may stop if a programming vulnerability is exploited, or the way the service handles resources it uses.
Preventing Denial of Service
Cheap validation first: Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soon as possible.
Prevent single point of failure
Avoid highly CPU consuming operations
Handle Exceptions
Threading: Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations
Identify resource intensive pages and plan ahead.
HTTP Verb Tampering
HTTP Verb Tampering
The full HTTP 1.1 specification defines the following valid HTTP request methods, or verbs:
HTTP Verb Tampering
PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.
DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
CONNECT: This method could allow a client to use the web server as a proxy.
TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page).
HTTP Verb Tampering
As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.
Preventing HTTP Verb Tampering
Restrict HTTP methods
Apply a whitelist of permitted HTTP Methods e.g. GET, POST
Reject all requests not matching the whitelist with HTTP response code 405 Method not allowed.
Make sure the caller is authorized to use the incoming HTTP method on the resource collection, action, and record
Security Tips in EE
Update Regularly
Keeping your installation up-to-date is the easiest way to keep your site secure. ExpressionEngine’s security measures are routinely updated to stay ahead of the ever evolving exploit landscape.
Limit User Permissions
You should only provide people with the minimum permissions they need to do what they need to do. In ExpressionEngine parlance, don’t put everyone in the Super Admin member group.
This also applies to access to your webserver. Do not provide others with FTP or SSL access unless it is absolutely necessary. Periodically review your access settings and revoke any accounts and permissions that are no longer required.
Use SSL Certificates
If possible, you should use an SSL certificate on your site and restrict all traffic to https only. This can help prevent password sniffing on insecure networks such as public wifi hotspots.
Create a Password Policy
ExpressionEngine’s password requirements are customizable. We recommend implementing a reasonable policy:
Restrict File Types
When setting up a file upload directory, forum attachments, or private message attachments you should restrict it as much as you are able. If you only expect images to be uploaded, you should only allow images. Be as strict as you can be initially, and loosen requirements on a case-by-case basis.
Remove Unused Add-ons and Applications
When an add-on or other application on the server is no longer used, we recommend removing the associated code.
Do you trust this developer/company?
Disable Uploaded Executables
ExpressionEngine prevents the upload of code to your server when using any of the native file upload tools including the custom file field in the control panel and Channel Forms, forum attachments, and private message attachments.
However, in the unlikely event that ExpressionEngine’s default safeguards are bypassed, an insecure addon is installed, outdated code is exploited, or your server is compromised in any other way, we recommend using your web-servers native security features to further lock down file upload directories.
Limiting Template Access
{exp:query sql="
UPDATE `exp_members`
SET `group_id` = '1'
WHERE `email` = 'myemail@evil.com'
"}
Thank you!
Questions?
Matt Johnson