1. Web Security A Programmers Perspective
9/22/2018
Web Security A Programmers Perspective
Author: Jacob Johansen

2. Brief History of the Internet
9/22/2018
Brief History of the Internet
9/22/2018
ARPANET
Founded in 1969
Advance Research Project Agency
Funded by the Department of Defense
Security
Designed for Openness and Flexibility
ARPANET: Began in 1969
It was funded by the advance research project agency which was part of the Department of Defense
It was funded to create a network that was resilient to network disconnection of nodes; basically being able to find another route to wanted location
Security: The project was originally designed for openness and flexibility, Security was not one of the main goals of the project.
Conclusion: Security was over looked from the beginning

3. Types of Intruders Who? Why? Adolescents
9/22/2018
Types of Intruders
9/22/2018
Who?
Adolescents
College Students / Researchers
Spy's ( Companies, Nations)
Thief
Protester
Why?
Entertainment
Intellectual Challenge
Sense of Power
Political attention
Financial gain

4. Major Historical Events
9/22/2018
Major Historical Events
9/22/2018
Heartland Payment Systems – March 2008
134 Million Credit Cards Stolen
140 Million Dollars in damages.
SQL Injection based attack
Stuxnet – 2007 to 2010
Most likely Developed by Nation State attackers
Gawker Media – December 2010
Allowed for hacking of other sites.
Heartland Payment System – 2008
134 million credit cards stolen
This attack used SQL Injection as part of the attack
Security analysts had warned retailers for several years that there was SQLI vulnerability.
Stuxnet:
This event does not relate directly to this topic but it shows that nation states have started to become involved in hacking for malicious purposes.
Gawker:
is an example of data being stored poorly. Gawker stored passwords of their users in a format that was easy for hackers to understand. Which then help to attack different accounts that Gawkers users were also a part of.
Conclusion: Note that the majority of major historical events involved sql injections and all involved malicious code injection of some kind or another

5. Overview SQL Injection (SQLi) Cross Site Scripting (XSS)
9/22/2018
Overview
9/22/2018
SQL Injection (SQLi)
Cross Site Scripting (XSS)
Cross Site Request Forgery
Note: That these topics are all fairly easy to understand but its very easy to leave these vulnerabilities open. These types of vulnerabilities still show up today all the time.
So for the rest of the presentation, I will go over what they are and how to help mitigate damage from them. Web security is always shifting.

6. 9/22/2018
SQL Injection
9/22/2018
SQL Injection is where an attacker is able to insert their sql “code” into a query call to the database.
SQL Injection – Injection of additional SQL logic into an SQL statement.

7. SQL Injection – continued
9/22/2018
SQL Injection – continued
9/22/2018
What an SQL Injection vulnerability looks like.
statement = "SELECT * FROM users WHERE uname ='" + userName + "';"
userName could equal
johansenj
statement = "SELECT * FROM users WHERE uname =‘johansenj’;"
The first example which uses my username johansenj would just return a single user with johansenj assuming the user name exists and the user name is unique.
The Second example would return every record in the table users because as it checks each record, the check is always true because ‘1’ = ‘1’ is always true.
Note that if there is sensitive information in those records that all that information would flow through also. Ie. Password, name, birthday, address, zip, city, , credit card … and any other data field in the system.
This is the basis of all SQL injection, getting your logic interpreted by the database and then displayed back to you.
userName could equal
J’ OR ‘1’ = ‘1’;--
statement = "SELECT * FROM users WHERE uname =‘J’ OR ‘1’ = ‘1’;--’;"

8. SQL Injection Mitigation
9/22/2018
SQL Injection Mitigation
9/22/2018
Main Defenses
Prepared Statements
Stored Procedures
Escaping all user supplied Input
Additional Defenses
Least Privilege
Input Validation
Field Encryption

9. Prepared Statements Template Statements
9/22/2018
Prepared Statements
9/22/2018
Also known as parameterized queries
$stmt = $dbh->prepare(‘SELECT * FROM users WHERE uname = ?’);
$stmt->execute($username);
Template Statements
Separation of Statement Logic and User input
Best Practice
A prepared statement first parses the template statement.
This way the database already knows the logic of the statement you want.
The second step binds the values with the prepared statement.
this passes the values you wish to test against into the prepared statement without changing the logic of the statement.
This method is considered best practice for writing sql statements in an application.

10. Stored Procedures Similar to Prepared Statements
9/22/2018
Stored Procedures
9/22/2018
Similar to Prepared Statements
Logic kept in the database
Still can have SQL injection vulnerability
SP_Execute, Execute, or Exec
parameterized queries should still be used
Parameter Injection and Parameter Shifting
$sth = $dbh->prepare("call do_it_1(?);");
$sth->bind_param(1, \$count);
$sth->execute();
Key words such as sp_execute, execute or exec should be watch for in stored procedures as those are key commands in stored procedures that would allow for possible SQL injection vulnerabilities.

11. Escaping all user supplied Input
9/22/2018
9/22/2018
Escaping all user supplied Input
Replace dangerous characters with escaped versions.
Helpful for retrofitting
Can be a more cost effective solution.
Not as successful at preventing SQLi
Well maintained library is suggested.
Retrofitting
This method is a cost effective way of retrofitting older applications
There are still SQL injection vulnerabilities.
a malicious user only needs to find a case that is not found and replaced by your Escaping library
it is best to use a library that is actively maintained.
it is not recommended to recreate your own library.

12. Additional Defenses Least Privilege Input Validation Field Protection
9/22/2018
Additional Defenses
9/22/2018
Least Privilege
Database set up
Input Validation
Field Protection
Hashing
Encryption
Zip code: \d{5}(-\d{4})?
States Example: (AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU| HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN| TX|UT|VT|VI|VA|WA|WV|WI|WY)
Least Privilege
setting access to tables and stored procedures based on whether a user needs access to tables and stored procedure
Input Validate
regex:
\d{5} - represents a string of 5 numeric characters
? – means match 1 or 0 times
Field Protection
hashing:
Using proper pass storage techniques such as using hashing methods that are strong enough.
adding salt – a series of characters to make the password more unique before hashing. This helps make hash look up tables ineffective for attackers
and helps keep your users password secure if there was a data breach
encryption:
this should be used to store users critical sensitive information such as credit cards. This should not use the built in one that come with the database as it decrypts the information upon retrieval from the database, so this would not help with a SQLi

13. Cross Site Scripting (XSS)
9/22/2018
9/22/2018
Cross Site Scripting (XSS)
What is it?
Cross Site Scripting is when a malicious user find a way to inject HTML and JavaScript into an application and then have it Executed.
A Name for better comprehension: HTML Injection
Not necessarily to transfer information between web domains.
Attacker can do almost anything an Authentic user can.
Cross site scripting is that a malicious user has found a way to inject their code into your web page and got it to execute when the browser is loaded or when a user does some action to trigger the malicious script.
A more appropriate name for cross site scripting would be HTML Injection, as it does not necessarily have to transmit data across multiple domains, but there have been scripts that have.
Also this is a vulnerability that virtually allows the attacker to do anything a legitimate user can do

14. 9/22/2018
Persistent
9/22/2018
Is an attack which the injected HTML and JavaScript is stored in the applications database
The Malicious code is then injected by the server into requested pages
Process
The attacker executes a command on the server which saves the malicious code.
The server then injects the malicious code into web requests by valid users
The users web browser then executes the malicious code sending commands they did not initiat.
Persistent xss refers to the method of putting the vulnerability into the database, and then displayed back to normal visitors to the page.
(2012) I was testing an application and made an example of the vulnerability. I took advantage of having users post privileged information into a spot that I, a less privileged user, could see… what could be worse is finding a browser vulnerability also and sending it to an off site domain.
The MySpace Sammy worm of 2005 is another example of this…
It added
The MySpace Sammy worm was the first of its kind, a xss worm. It spread to over 1 million unique users.

15. 9/22/2018
Non-Persistent
9/22/2018
Is an attack which the injected HTML and JavaScript is stored within a link to the site in question
The malicious code is taken from the link upon a request and reflected back into the webpage
Process
An attacker send a link with malicious code inserted into it.
The user clicks on the link.
The webserver takes information form the link, mainly the malicious code, inserts the code into the generated page.
Upon the user receiving the compromised page, the code executes.
A reflected attack is typically delivered via or a location for users to post links.
These attacks are normally targeted at a smaller group of individuals.
The user clicks on the link, the link has embedded code, the web server process the link and returns a page that contains code from the request, the victims web browser then executes.

16. Prevention Techniques
9/22/2018
Prevention Techniques
9/22/2018
Follow “The Open Web Application Security Project” xss prevention rules
Rules
Never insert untrusted data except in allowed areas
Escape before inserting into content area
Escape before inserting into common attributes
Escape before inserting into JavaScript data values
Escape JSON values in an HTML context and use JSON.parse
Escape CSS and strictly validate
Escape URL before inserting untrusted data
Sanitize HTML markup with library designed to do the job

17. Cross Site Request Forgery
9/22/2018
Cross Site Request Forgery
9/22/2018
What is it?
Cross Site Request Forger is a web command that originates from a different origin than that of the valid site.
What causes the vulnerability
Web is stateless
Browsers Don’t Partition Authentication to Single sites.
Cross site request forgery is where the user is authenticated to a website and the website allows them to run commands.
The vulnerability appears when the site in question verified the user is on a particular browser but does not guarantee that it is the user that made the request to the server
This can be problematic in that an attacker can run a series of commands to fool the server into thinking that the user is sending the commands from their web apps.

18. CSRF - continued What does a simple example look like?
9/22/2018
CSRF - continued
9/22/2018
What does a simple example look like?
Web site being attacked: bank.com
Web Command: Transferring money to a different account
Command Parameters:
Acct: the account in which to transfer money to.
Amount: the amount of money to transfer to an another account.
This can also be automated with JavaScript.
<a href="
This one provides a link that when clicked will transfer $100,000 to the account ATTACKER
It assumes and hopes that who ever clicks on the link is already logged onto bank.com
But you can also create JavaScript to do the same thing and without needing the user to click anything.

19. Protection Strategies
9/22/2018
Protection Strategies
9/22/2018
Synchronizer Token Pattern
HTML embedded
Double Submit Cookies
Encrypted Token Pattern
Prevention without a Synchronizer Token
Checking The Referer Header
Checking The Origin Header
Challenge-Response
Yes Refere, it was misspelled in the documentation; therefor it continues to be misspelled in the implementation.

20. Token – HTML Embedded Token Generation How this method works?
9/22/2018
Token – HTML Embedded
9/22/2018
Token Generation
Uses Secure random number generator and hashing algorithms
Creates a Unique token.
How this method works?
User is Authenticated
Token Generated
Token Stored in database ( for later comparison)
Token is then inserted into webpages on all requests
Upon a web request, browser sends the token back with the data
Webserver then compares token sent back with the one in the database
If the tokens match the server executes commands as normal
The embedded token needs to be generated with an algorithm that uses a secure random number generator and hashing algorithms that create a unique token
The token is then save with the users session data and embedded in the forms the site generates for post requests
When the user makes a valid request using your application, the request comes back with the token, which is then compared with the token stored in the database.
If there is no token or it is the wrong token, then you know its not the authenticated user sending the request.

21. Double Submit Cookie Token generation How it works
9/22/2018
Double Submit Cookie
9/22/2018
Token generation
uses a cryptographically strong pseudorandom value
How it works
User is Authenticated
Token Generated
Token is stored in an (HTTP only) Cookie
Token is then inserted into webpages on all requests
Upon a web request, browser sends the token back with the data along with the (HTTP only) Cookie
Webserver then compares tokens sent back (There is no database request on invalid requests)
If the tokens match the server executes commands as normal
The site generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's browser.
The website then puts the token in the forms when the user requests it from their website like in the HTML embedded method.
The thing that is different is that the token in this case normally represents the session id also, which can make this method vulnerable to session hijacking
But it compares the session id in the form with the “secret” cookie (HTTPonly) and that is sufficient to prevent a cross site request forgery

22. Encrypted Token Token Generation How it works Encryption Token Pattern
9/22/2018
Encrypted Token
9/22/2018
Token Generation
The token is the encryption of the user ID, a timestamp, and a nonce
How it works
User is Authenticated
Token Generated
Token is then inserted into webpage
Upon a web request, browser sends the token back with the data
The Token is then Decrypted (Successful Decryption would mean a valid request)
A new token is generated and sent back with the response
Encryption Token Pattern
Benefits: Session management, protects against XSS on other subdomains, no database calls for validation.
Token comprised of the encrypted user ID, a timestamp value and a nonce
The encrypted token is stored in a hidden field on the page, when the user makes a request form the site it uses AJAX(Asynchronous JavaScript and XML) and sends the data back in a custom http header or it can send the encrypted token back over a post in the hidden field, the server then uses its key to decrypt the token and use the information in the token.
The server can either generate a new token for the session or use the current one for the current session depending on the depending on the time out length of the key
The time stamp on the encrypted token allows the server to know if a replay attack has been attempted.
It does help against subdomain XSS attacks, but does not protect against internal XSS attacks

23. Non-Synchronizer Token
9/22/2018
Non-Synchronizer Token
9/22/2018
Checking The Referer Header
A web header which adds the domain from which the web request came from if it is an unsecured address
This won’t match in the event of an attack or if coming from a secured address (HTTPS)
Checking The Origin Header
A web header which adds the domain from which the web request came from if it is a secured address
Challenge-Response
CAPTCHA
Re-Authentication (prompting for password again)
One-time Token (Google’s Authenticator)
Challenge Reponses do impede a users experience, but does help against cross site scripting as well.
Referer, is yes misspelled, but that’s the way it is defined and has continued to be used… and can be used to help determine where the request came from. This has to be implemented correctly or your application can lose its protection (site.com.attacker.com) this also comes up blank from secure site (https)
Origin will present the origin domain for secure http sites
Challenger response
CAPTCHA
Re-Authentication(password)
One-time token (Google’s Authenticator)
The challenge responses are for very secure items, and it does affect the users experience.
Out of all the methods above none of them will help prevent against a XSS attack accept for the challenge responses

24. 9/22/2018
Questions?
9/22/2018