Transcript CSCE 790 – Secure Database Systems

Web Application Access
to Databases
Logistics
Test 2: May 1st (24 hours)
 Extra office hours: Friday 2:30 – 4:00 pm
 Tuesday May 5th – you can review your
final before final grades are submitted

2
Three-Tier Architecture
DB
DB Server
DB Server
Application
Server
Web
Server
Application
Server
Web
Server
Internet
Clients
Application
Server
Web
Server
Web
Server
3
3
Options
1. Code in a specialized language is
stored in the database itself (e.g.,
PSM, PL/SQL).
2. SQL statements are embedded in a
host language (e.g., C).
3. Connection tools are used to allow a
conventional language to access a
database (e.g., CLI, JDBC, PHP/DB).
4
4
Code Security
Input validation!
5
Process Memory Organization

Process memory: 3 regions
 Text:
fixed by the program, includes code,
read-only (attempt to write: segmentation
fault)
 Data: initialized and uninitialized data
 Stack: stores application data and control
data

Low-level languages: direct access to
application memory
6
Buffer Overflow
Inserting more data into the buffer than it
can handle
 Stack-base attacks most common
 Most vulnerable languages: C, C++

7
Exploitation of Buffer Overflow
Lack of input validation
 Default case: mistrust input

 Never
allow input over the maximum length to
be stored in a variable
 Process input one character, word, or byte at
a time
 Never leave extra input on the incoming line
8
Cases and Effects
 Overwriting local variables  change the
program’s behavior
 Overwriting a return address  execution will
resume at the attacker’s specified address,
executing the attacker’s code
9
Defensive Measures
 Canaries
 Pad buffers with a random, secret value
determined at compile time or runtime
 Check to see if the secret value is the
same before allowing transfer of control
 If you smash the boundaries of the array
on the stack, how do you know what the
values are?
10
Defensive Measures
Randomize locations for loading of code
 Prevent data from being executed
 Stop using unsafe code! strcpy -> strlcpy,
strncat -> strlcat, gets -> fgets
 Use a safer language
 Anything with bounds checking – Java, C#,
VB.net, Python, Perl, Ruby, PHP, D…
 …but be careful when calling C/C++
libraries

11
Defensive Measures
 Input validation
 Allow only input that you expect


Example: [a-zA-Z0-9]+ on usernames
Prevent some shellcode
 Run static code analyzers
 Detects use of unsafe (unbounded)
functions
12
SQL Injection
 Attacker
provides malformed data to
application
 Application uses data to create a SQL
statement via string concatenation
 Allows attacker to change the semantics of
the SQL query
 Why use concatenation?
 Don’t
know a safer way
 Laziness
13
Spotting SQL Injection
Takes
user input
Does not check user input validity
Uses user-input data to query a database
Uses string concatenation or string
replacement to build the SQL query or uses
SQL EXEC command
14
Redemption
 Thou
shalt never trust input to SQL
statements
 Always

validate
Use regular expressions to parse input
 Use
prepared or parameterized SQL
statements

Use placeholders or binding
15
Web Application
Vulnerabilities
16
Biggest Threats to Web Applications
Cross-site scripting (XSS)
 Cross-site request forgeries (CSRF)
 Remote file uploads, (buffer overflow, SQL
injection, etc.)


Trust between the client’s machine and
the web applications.
17
XSS – Server trusts client



Inject client-side script into Web pages
Client views web page  download script
Used for bypass access controls such as the same origin
policy
 Permits scripts running on pages originating from the
same site ( scheme, hostname, and port number) to
access each other's Document Object Model with no
specific restrictions
 XMLHttpRequest and Robots.txt
18
How to avoid XSS?
Scrub all input
 Escape output for display
 Use trusted solutions when available
 Use separate variables for scrubbed input

19
Cross-site request forgery –
Client trusts server
Exploits the trust between server and
client machine
 Mostly http requests and responses
 Based on how web pages are delivered
along with images and other web content

20
Prevent CSRF



Require verification and stages for sensitive
applications
Use anti-CSRF tokens in your forms and
processing
Use post as the mean of taking form input
 Get: encodes the data of the form into the url
of the recipient, appending it to the query
string of the request
 Post: encodes it as a message
21
Unrestricted file upload
Users may upload malicious files
 Uploaded files can be called by a url (if
stored on the web server)
 Example: php

 Embedded
in image files
 Compile php code
22
Avoid file upload problems





System should determine file name
Do not allow users to access the folders where
content is uploaded
Parse file extensions carefully or set your own
file parser
White list extensions
Be secure with the .htaccess file (controls
accesses to the files on the server
23