introduction to software security web security...

Seong-je Cho

Spring 2019

Computer Security & Operating Systems Lab, DKU

Introduction to Software Security

Web Security Basics(server-side attacks)

- 2 -

Sources / References

Myrto Arapinis, Computer Security: INFRA10067, University of Edinburgh – Web security: web basics

Nicholas Weaver, Computer Science 161: Computer Security, Berkeley

Please do not duplicate and distribute

Computer Security & OS Lab, DKU

- 3 -

Contents

Web basics

Web applications

Web security

OWASP Top 10 risks

Server-side attacks Command injection

SQL injection


Web Security: web basics

Myrto Arapinis

School of Informatics

University of Edinburgh

November 13, 2017


- 5 -

Web Applications

Web application code runs on Web servers or App servers

takes input from web users (via Web server)

interacts with the database and 3rd parties.

prepares and outputs results for users (via Web server)

Dynamically generated HTML pages

A webpage can have content coming from 10-20 different domains


HTTP (Hypertext Transfer Protocol): A common data communication protocol on the web

- 6 -

URLs

Protocol: protocol to access the resource (http, https, ftp, . . . )

host: name or IP address of the computer the resource is on

(File) Path: path to the resource on the host

Resources can be static (file.html) or dynamic (do.php)

URLs for dynamic content usually include arguments to pass to the process (argt1, argt2)

Port (optional): Each protocol has a default port

Query (optional): Sent to server

Fragment: Local to the client

Only accessible to scripts in the web page


- 7 -

Interacting with Web Servers

An interaction with a web server is expressed in terms of a URL (plus an optional data item)

URL components:


- 8 -

HTTP requests


- 9 -

HTTP responses


- 10 -

HTTP responses


Server shows Webpageto client browser

- 11 -

How is state managed in HTTP sessions

HTTP is stateless: when a client sends a request, the server sends back a response

but the server does not hold any information on previous requests

The problem: in most web applications a client has to access various pages before

completing a specific task and the client state should be kept along all those

pages. How does the server know if two requests come from the same browser?

Example: the server doesn't require a user to log at each HTTP request

The idea: insert some token into the page when it is requested and get that token

passed back with the next request

Two main approaches to maintain a session between a web client and a web

server

use hidden fields

use cookies


- 12 -

Hidden fields (1)

Example: the web server can send a hidden HTML form field along with a unique session ID as follows:

<input type="hidden" name="sessionid" value="12345">

When the form is submitted, the specified name and value are automatically included in the GET or POST data.


- 13 -

Hidden fields (2)


- 14 -

Cookies (1)

A cookie is a small piece of information that a server sends to a browser and stored inside the browser. A cookie has a name and a value, and other attribute such as domain and path,

expiration date, version number, and comments

The browser automatically includes the cookie in all its subsequent requests to the originating host of the cookie

Cookies are only sent back by the browser to their originating host and not any other hosts. Domain and path specify which server (and path) to return the cookie

A server can set the cookie's value to uniquely identify a client. Hence, cookies are commonly used for session and user management

Cookies can be used to hold personalized information, or to help in on-line sales/service (e.g. shopping cart). . .


- 15 -

Cookies (2)

http response contains cookie

Browser maintains cookie jar

A cookie has several attributes:


Web Security: security goals


- 17 -

Desirable security goals

Integrity: malicious web sites should not be able to tamper with integrity of our computers or our information on other web sites

Confidentiality: malicious web sites should not be able to learn confidential information from our computers or other web sites

Privacy: malicious web sites should not be able to spy on us or our online activities

Availability: malicious parties should not be able to keep us from accessing our web resources


- 18 -

Security Goals

1. visiting evil.com should not infect my computer with malware, or read and write fileDefenses: Javascript sandboxed, avoid bugs in browser code, privilege separation, etc.

2. visiting evil.com should not compromise my sessions with gmail.com

Defenses: same-origin policy – each website is isolated from all other websites

3. sensitive data stored on gmail.com should be protected


- 19 -

Same-origin policy

Each site in the browser is isolated from all others


Origin = protocol + hostname + port

Multiple pages from the same site are not isolated

- 20 -

Same-origin policy

One origin should not be able to access the resources of another origin

Javascript on one page cannot read or modify pages from different origins.

The contents of an iframe have the origin of the URL from which the iframe is served; not the loading website.

The origin of a page is derived from the URL it was loaded from

Special case: Javascript runs with the origin of the page that loaded it


- 21 -

Threat model

Web attacker

controls evil.com

has valid SSL/TLS certificates for evil.com

Secure Socket Layer (SSL) Transport Layer Security (TLS)

victim user visits evil.com

Defacement

Attackers can change cookie with Javascript

Network attacker

controls the whole network: can intercept, craft, send messages


- 22 -

OWASP TOP 10 Web security Flaws


OWASP (Open Web Application Security Project)

OWASP Top 10 Application Security Risks

2004, 2007, 2010, 2013, 2017, …

Server-side attacks


- 24 -

Injection attack

OWASP definition

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query.

The attacker's hostile data can trick the interpreter into executing unintended

commands or accessing data without proper authorization.

Injection flaws occur when an attacker can send hostile data to an interpreter.

source: https://www.owasp.org/index.php/Top_10-2017_Top_10

NoSQL : non SQL DB

LDAP: Lightweight Directory Access Protocol

We are going to look at:

Command injection attacks

SQL injection attacks


https://www.owasp.org/index.php/Top_10-2017_Top_10

- 25 -

Command injection: a simple example (1/2)

Service that prints the result back from the Linux program whois

Invoked via URL like (a form or Javascript constructs this URL):

http://www.example.com/content.php?domain=google.com

Possible implementation of content.php

<?php

if ($_GET['domain']) {

<? echo system('whois '.$_GET['domain']); ?>

}

?>


- 26 -

Command injection: a simple example (2/2)

This script is subject to a command injection attack! We could invoke it with the argument www.example.com; rm *

http://www.example.com/content.php?

domain=www.google.com; rm *

Resulting in the following PHP

<? echo system('whois www.google.com; rm *'); ?>


- 27 -

Other Command Injection


Example: PHP server-side code for sending email

Attacker can post

OR

$email = $_POST[“email”]$subject = $_POST[“subject”]system(“mail $email –s $subject < /tmp/joinmynetwork”)

http://yourdomain.com/[email protected] &subject=foo < /usr/passwd; ls

http://yourdomain.com/[email protected] & subject=foo;echo “evil::0:0:root:/:/bin/sh">>/etc/passwd; ls

mailto:[email protected]

mailto:[email protected]

- 28 -

Defense: Input escaping

<? echo system('whois'.escapeshellarg($_GET['domain'])); ?>

escapeshellarg() adds single quotes around a string and quotes/escapes any existing single quotes allowing you to pass a string directly to a shell function and having it be treated as a single safe argument


- 29 -

Command injection recap

Injection is generally caused when data and code share the same channel:

"whois" is the code and the filename the data

But ';' allows attacker to include new command

Defenses include input validation, input escaping and use of a less powerful API

Recap = recapitulation: 요약, 개요, 요점의되풀이


SQL Injection


• Malicious SQL statements run on a database and thus attack the server

Firewall does not block some requests via certain ports

● Ports 80 and 443 are usually allowed through firewalls

Firewalls can not prevent URL interpretation attacks, Input validation attacks, SQL Query Poisoning, HTTP session hijacking, Impersonation, …

- 31 -

Web Applications


Security concern

● Poorly written scripts with inadequate input validation

● Sensitive data stored in world-readable files

Can Firewalls prevent … ?

- 32 -

Databases

Web server connects to DB server:

Web server sends queries or commands according to incoming HTTP requests

DB server returns associated values

DB server can modify/update records

SQL: commonly used database query language


- 33 -

SQL SELECT

Retrieve a set of records from DB:

SELECT field FROM table WHERE condition # SQL comment

returns the value(s) of the given field in the specified table, for all records where condition is true

Example:


SELECT password FROM user_accounts WHERE username='alice'

returns the value 01234

- 34 -

SQL INSERT

Retrieve a set of records from DB:

INSERT INTO table VALUES record # SQL comment

adds the value(s) a new record in the specified table

Example:


INSERT INTO user_accounts VALUES ('eve', 98765)

- 35 -

Other SQL commands

DROP TABLE table

deletes entire specified table

Semicolons separate commands:

Example:

INSERT INTO user_accounts VALUES ('eve', 98765);SELECT password FROM user_accounts WHERE username='eve'

returns 98765


- 36 -

SQL command


WebServer

WebBrowser(Client)

DB

EnterUsername

&Password

SELECT passwdFROM user_accounts

WHERE username IS ‘$username’

Attacker will modify

- 37 -

SQL Injection : An Example


WebServer

WebBrowser(Client)

DB

EnterUsername

&Password

SELECT passwordFROM user_accounts

WHERE username IS ‘’; DROP TABLE

USERS; -- ‘

Eliminates all user accounts

Attacker modifies input

- 38 -

SQL injection: a simple example

The web server logs in a user if the user exists with the given username and password.


It sees if results exist and if so logs the user in and redirects them to their user control panel

- 39 -

SQL injection: a simple example


• Login as admin

• Drop user_accounts table

- 40 -

SQL Injection


- 41 -

SQL Injection


SELECT pizza, toppings, quantity, order_day FROM ordersWHERE userid=4123 AND order_month=10

Normal SQL Query

Attacker is able to● Combine the results of two queries● Empty table from first query with the sensitive credit card info of all users from

second query

…

WHERE userid=4123 AND order_month=0 AND 1=0UNION SELECT cardholder, number, exp_month, exp_yearFROM creditcards

Malicious SQL Query

- 42 -

Defense: prepared statements

Creates a template of the SQL query, in which data values are substituted

Ensures that the untrusted value is not interpreted as a command


- 43 -



Parse Tree for a Prepared Statement

- 44 -


So What Happens to DB Table?


Parsing DB Table …

- 45 -

Prepared Statements (usually used in Java)

Metacharacters (e.g. ‘) in queries provide distinction between data & control

Most attacks: data interpreted as control /alters the semantics of a query/cmd

Bind Variables: ? placeholders guaranteed to be data (not control)

Prepared Statements allow creation of static queries with bind variables → preserves the structure of intended query

Example


PreparedStatement ps =

db.prepareStatement("SELECT pizza, toppings, quantity, order_day "

+ "FROM orders WHERE userid=? AND order_month=?");

ps.setInt(1, session.getCurrentUserId());

ps.setInt(2, Integer.parseInt(request.getParamenter("month")));

ResultSet res = ps.executeQuery();Bind Variable:

Data Placeholder• query parsed w/o parameters

• bind variables are typed e.g. int, string, etc…*

- 46 -

Summary

Web applications

Web security basics

OWASP Top 10 Risks

Server-side attacks

Command injection

SQL injection

…

Web Goat

Client-side attacks Cross Site Scripting (XSS)

Content Spoofing


introduction to software security web security...

Documents