/
Web Security A Programmers Perspective Web Security A Programmers Perspective

Web Security A Programmers Perspective - PowerPoint Presentation

sherrill-nordquist
sherrill-nordquist . @sherrill-nordquist
Follow
350 views
Uploaded On 2018-11-12

Web Security A Programmers Perspective - PPT Presentation

Author Jacob Johansen 1 Brief History of the Internet ARPANET Founded in 1969 Advance Research Project Agency Funded by the Department of Defense Security Designed for Openness and Flexibility ID: 728457

2013 token injection web token 2013 web injection request code site sql user malicious users html cross stored server javascript link executes

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Web Security A Programmers Perspective" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Web SecurityA Programmers Perspective

Author: Jacob Johansen

1Slide2

Brief History of the Internet

ARPANETFounded in 1969

Advance Research Project AgencyFunded by the Department of Defense

Security

Designed for Openness and Flexibility

11/21/2013

2Slide3

Types of Intruders

Who?AdolescentsCollege Students / ResearchersSpy's ( Companies, Nations)

ThiefProtesterWhy?Entertainment

Intellectual Challenge

Sense of Power

Political attention

Financial gain

11/21/2013

3Slide4

Major Historical Events

Heartland Payment Systems – March 2008134 Million Credit Cards Stolen

140 Million Dollars in damages.SQL Injection based attack

Stuxnet

– 2007 to

2010

Most likely Developed by Nation State attackersGawker

Media – December 2010Allowed for hacking of other sites.

11/21/2013

4Slide5

Overview

SQL Injection (SQLi)Cross Site Scripting (XSS)

Cross Site Request Forgery

11/21/2013

5Slide6

SQL Injection

11/21/2013

6

SQL Injection – Injection of additional SQL logic into an SQL statement.Slide7

SQL Injection – continued

What an SQL Injection vulnerability looks like.

11/21/2013

7

statement = "

SELECT

*

FROM

users

WHERE

uname

=

'" +

userName

+ "';"

userName

could equal

johansenj

statement = "

SELECT

*

FROM

users

WHERE

uname

=

johansenj

;"

userName could equal

J’ OR ‘1’ = ‘1’;--

statement = "

SELECT

*

FROM

users

WHERE

uname

=

J’ OR ‘1’ = ‘1

’;

--

;

"

Slide8

SQL Injection Mitigation

Main DefensesPrepared Statements

Stored ProceduresEscaping all user supplied InputAdditional DefensesLeast Privilege

Input Validation

Field Encryption

11/21/2013

8Slide9

Prepared Statements

Also known as parameterized queries

11/21/2013

9

$

stmt

=

$

dbh

->

prepare(‘

SELECT

*

FROM

users

WHERE

uname

=

?’);

$

stmt

->execute

($

username);

Template Statements

Separation of Statement Logic and User input

Best PracticeSlide10

Stored Procedures

Similar to Prepared StatementsLogic kept in the databaseStill can have SQL injection vulnerability

SP_Execute, Execute, or Execparameterized queries should still be

used

Parameter Injection and Parameter Shifting

11/21/2013

10

$

sth

=

$

dbh

->

prepare("call

do_it_1(?);");

$

sth

->

bind_param

(1

, \$count);

$

sth

->execute();Slide11

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.

11/21/2013

11Slide12

Additional Defenses

Least PrivilegeDatabase set upInput Validation

Field Protection

Hashing

Encryption

11/21/2013

12

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)Slide13

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.

11/21/2013

13Slide14

Persistent

11/21/2013

14

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

.Slide15

Non-Persistent

11/25/2013

15

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.Slide16

Prevention Techniques

Follow “The Open Web Application Security Project” xss prevention rules

RulesNever insert untrusted data except in allowed areasEscape 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.parseEscape CSS and strictly validate

Escape URL before inserting untrusted dataSanitize HTML markup with library designed to do the job

11/21/2013

16Slide17

Cross Site Request Forgery

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 vulnerabilityWeb is statelessBrowsers Don’t Partition Authentication to Single sites.

11/21/2013

17Slide18

CSRF - continued

What does a simple example look like?Web site being attacked: bank.com

Web Command: Transferring money to a different accountCommand 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.

11/21/2013

18

<a

href

="

http://

bank.com/

transfer.do?acct

=

ATTACKER&amount

=100000

">

Pictures</

a>Slide19

Protection Strategies

Synchronizer Token PatternHTML embedded

Double Submit CookiesEncrypted Token PatternPrevention without a Synchronizer Token

Checking The

Referer

HeaderChecking The Origin HeaderChallenge-Response

11/21/2013

19Slide20

Token – HTML Embedded

Token GenerationUses Secure random number generator and hashing algorithmsCreates a Unique token.

How this method works?User is AuthenticatedToken Generated

Token Stored in database (

f

or l

ater comparison)Token is then inserted into webpages on all requestsUpon a web request, browser sends the token back with the data

Webserver then compares token sent back with the one in the databaseIf the tokens match the server executes commands as normal

11/21/2013

20Slide21

Double Submit Cookie

Token generationuses a cryptographically strong pseudorandom value How it

worksUser is AuthenticatedToken GeneratedToken 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

11/24/2013

21Slide22

Encrypted Token

Token GenerationThe token is the encryption of the user ID, a timestamp, and a nonce

How it worksUser is AuthenticatedToken Generated

Token is then inserted into

webpage

Upon a web request, browser sends the token back with the

dataThe 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.

11/24/2013

22Slide23

Non-Synchronizer Token

Checking The Referer HeaderA 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-ResponseCAPTCHARe-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.

11/25/2013

23Slide24

Questions?

11/21/2013

24