Secure Software - Computer Science

Download Report

Transcript Secure Software - Computer Science

Secure Software
Professional
Recommendations from
CWE/SANS
References
Material is from::
 2009 CWE/SANS Top 25 Most Dangerous Programming Errors, Version
1.4, Oct 29, 2009.
 CISA ® Certified Information Systems Auditor All-in-One Exam Guide, Peter
H Gregory, McGraw-Hill
Author:
 Susan J Lincke, PhD Univ. of Wisconsin-Parkside
Contributors: Megan Reid, Todd Burri
Funded by National Science Foundation (NSF) Course, Curriculum and
Laboratory Improvement (CCLI) grant 0837574: Information Security: Audit,
Case Study, and Service Learning.
Any opinions, findings, and conclusions or recommendations expressed in this
material are those of the author(s) and/or source(s) and do not necessarily
reflect the views of the National Science Foundation.
Objectives




Define attacks: Buffer overflow, SQL injection,
OS command injection, cross-site scripting,
cleartext, race condition, chatty error message
Define solutions: Sanitization, whitelist, blacklist,
nonce, character encoding (UTF-8), jail or
sandbox environment
Recognize major coding errors.
Modify a Requirements Document to include
Security Requirements
Problem:
Incorrect Input
Car Sale
Model: Chevrolet XR2
VIN:
12K4FG436DDE842
Sale to:
Phone: 911
Price $: 25.45
Status: New
Rubber Ducky
2222 Atlantic Ocean
Antarctica, NY, 00000
VISA: RUAFOOL444
Problem:
Buffer overflow
Name
Zzzzzzzzzz
Count
49, 425,222
State:
84
Return
address
Frame
pointer
0x246625
0x246625
Enter Name: Zzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzz
Fix: Input Validation
Assume all input is malicious! Validate:
 Length
 Type
 Syntax
 Context: Business Rules
Or Use
 Special input checkers



Struts or OWASP ESAPI Validation
API
Whitelist: List of acceptable input
Blacklist: Reject suspect input
Validate
First!!!
network
Problem:
Insecure Interaction
Between Components
real ->
network
fake ->
Program B
Program B*
Attack: Code is
reverse engineered
and modified to act
differently.
Problem:
Server assumes
validation
occurred in client
Does not recheck
Fix:
Server-Side Authentication
real ->


network
Perform authentication and input validation on
both client and server sides
Use encryption & hash between client & server
Problem:
SQL Injection





Java Original: “SELECT * FROM
users_table WHERE username=” + “’” +
username + “’” + “ AND password = “ +
“’” + password + “’”;
Inserted Password: Aa’ OR ‘’=’
Java Result: “SELECT * FROM
users_table WHERE
username=’anyname’ AND password =
‘Aa’ OR ‘ ‘ = ‘ ‘;
Inserted Password: foo’;DELETE
FROM users_table WHERE username
LIKE ‘%
Java Result: “SELECT * FROM
users_table WHERE
username=’anyname’ AND password =
‘foo’; DELETE FROM users_table
WHERE username LIKE ‘%’
Welcome to My System
Login:
Password:
Fix: Input Sanitization
Avoid dynamicallyconstructed query strings
 Disallow Meta-characters
Persistence Software:
 Oracle DBMS_ASSERT
 MySQL
mysql_real_escape_strin
g() for C, PHP
 Hibernate or Enterprise
Java Beans if used
properly

GUI - Validation
Business Logic
Persistence Layer
Database
Problem:
OS Command Injection
Problem: Command
Injection into SQL
 Inserts ‘|shell(“cmd /c
echo “ & char(124) &
“format c:”)|’
 Data
and control can
traverse same path
Welcome to My System
Login:
Password:
Fix:
Avoid OS Command Injection





Separate control information from data information.
 E.g. where data-> database, control defines application
Use library calls instead of external processes
Avoid external control of command input
Run code in “jail” or other sandbox environment (discussed in further
detail on next slide)
Provide lowest possible permissions for executable
Data: “Terry, Brian, Jerry, Ann, Louis, …”
Control: Start WPI session, parms -lmk
Define Jail & Sandbox
Jail
OS imposes resource limits
on programs. It may include:
 I/O bandwidth caps
 disk quotas
 network access
restrictions
 restricted file system
namespace
Sandbox
Quarantines an untrusted
program as it runs
 Can execute untested/
untrusted programs from
untrusted third-parties,
suppliers, and users.
Problem:
External Control of
Critical State Data
User-side data can be
modified:
 Cookies
 Configuration files
 Profiles
 Hidden form fields
 Environmental variables
 Registry keys
Fix:
Control Critical State Data
Understand all locations that are
accessible to attackers
 Do not keep state info on client without
using encryption and integrity checking
(e.g. HMAC)
 Store state info on server side only:
ASP.NET View State, OWASP ESAPI
Session Mgmt

Problem:
Insecure Interaction
Between Components



Web servers are
memoryless
Do not remember
sending a form to a
client – what type,
info
Client side can
remove checks,
insert other code,
return unexpected
data, etc.
Modifies
javascript
to avoid
error
checks
Problem:
Cross-Site Scripting




A reputable site has
links to an unknowingly
disreputable site
The disreputable site
generates a Javascript
or VB script, which gets
inserted into the
reputable company’s
html response.
The result looks like a
valid web page from the
reputable company.
E.g.: Error: Page not
found
reference
Should be
error (Not
Found)
Instead: fake
form
Fix:
Preserve Web Page Structure

Specify strong character encoding such as
UTF-8 or ISO-8859.
 Use
on output
 Check on input
 Or use other encoders: MS Anti-XSS library,
OWASP ESAPI Encoding, Apache Wicket

Validate not only input data, but all parts of
the HTTP input.
Problem:
Forgery
Also known as Cross-Site Request Forgery
Problem:
Improper Access Control
cache
Web Form for actual data
for www.abc.com/345
Fix:
Access Permissions

Use Role-Based Access






At least permissions: anonymous, normal, privileged, administrative
Verify access control at server side
Sensitive pages are never cached and must have active
authorization token
Only provide higher level access when you need it; always run with
the minimum possible authorization level
Check that files read have the required access level permissions;
administrators may not set them properly.
Use a good random number generator when generating random
session keys – if not random, attackers will figure out next key
sequence
Problem:
Incorrect Access Permissions
Database
Program
Sales
Sell on Web
Accounting
Sell to
Distributor
Adjust Price
Manufacturing
Add
Inventory
What permissions to use for these forms???
Ship Order
Fix:
Prevent Forgery
Name: Ann Winkler



Use a nonce for each
form (a number or
CAPTCHA generated
for a specific use, such
as session
authentication)
Verifier not predictable
If dangerous operation,
send a separate
confirmation request
Address: 2526 Pratt Ave
Racine WI
Phone: 262-595-2111
Interests: Horses, Movies, Travel
Security Code: Johnson Rivers
Security Code:
Johnson
Submit
Rivers
Problem:
Cleartext Transmit of Sensitive Info
Login: Ginger Password: Snap
Fix:
 Encrypt data with standard, reliable encryption
before transmission
Problem:
Race Condition
Thread P1
cin >> input;
..
out = input;
cout << out;
..
Thread P2
..
cin >> input;
out = input;
..
cout << out;
Comment
// read in "hello" into global
// read in "good-bye" into global
// do a string copy (...use strcpy())
// print out "good-bye"
// print out "good-bye“
Result: Data Corruption & Denial of Service
Fix:
 Use Synchronization Primitives around critical code
 Minimize use of shared resources
 Test using artificial delays in race window
 Identify and trigger error conditions
Problem:
Chatty Error Messages
“Cannot find file:
C:/users/Lincke/valida
tion.txt”
“Invalid password for
login ID”
“Lab.cs.uwp.edu error:
divide by zero error”
Fix:
 Error messages
should avoid file,
network configuration,
and PII information.
 Must be helpful to
user
 Remove debug info
before release
Problem:
External Control of Path


If you download an external file or navigate to a URL – and execute
If you provide access to a file on your system

Attacker can insert ../../ and access files outside privilege.
Fix:
 Run as low-privilege user
 Provide fixed input values
 Run code in ‘jail’: Unix chroot jail and AppArmor
Submit File:
Enter pathname:
Browse
Browse
Problem:
Adopting Untrusted Software
Fix:
 Use monitoring tools that
examine processes as it
interacts with the OS




Truss (Solaris)
Strace (Linux)
FileMon, RegMon, Process
Monitor, Sysinternals
(Windows)
Sniffers, Protocol analyzers
Download
File
Free Software … Is it Safe?
Problem:
Other Security Errors
Find the errors:
Security() {
String contents, environment;
String spath = “security.dat”
File security = new File();
if (security.open(spath) >0)
contents = security.read();
environment = security.read();
else
print(“Error: Security.dat not found”);
}
Problem:
Other Security Errors
Find the errors:
Security() {
String contents, environment;
String spath = “security.dat”
File security = new File();
if (security.open(spath) >0)
contents = security.read();
environment = security.read();
else
print(“Error: Security.dat not
found”);
}
1.
Variables contents &
environment not initialized

Can cause problems if executed
in certain ways
 Attacker can initialize or read
variables from previous session
2.
“security.dat” is not full
pathname.

3.
File ‘security’ not closed


4.
File can be replaced if run from
another location
Leaves file open to attack
Keeps unnecessary resources
busy
Error message indicates file
name

Can give attacker important info
Problem:
More Security Errors
Find the errors:
purchaseProduct() {
password = “N23m**2d3”;
count = form.quantity; // input
total = count * product.cost();
Message m = new Message(
name,product,total);
m.myEncrypt();
server.send(m);
}
Problem:
More Security Errors
Find the errors:
purchaseProduct() {
password = “N23m**2d3”;
count = form.quantity;
total = count * product.cost();
Message m = new Message(
name,password,product,total);
m.myEncrypt();
server.send(m);
}
Errors:
1. Password is hardcoded

If attacker finds it, every
system can be broken into
before software is changed
on all computers
 Passwords may only be
stored in encrypted file
2.
Total may overflow, producing
very small number

3.
Input is not checked (could be
zero or invalid)
Encryption should be standard
algorithm

Home-written variety can be
broken into easily
Fix:
Test All Software!!!




Dynamic Tools: use large test suites such as fuzz
testing, robustness testing, and fault injection. Software
may slow down but should not crash or generate
incorrect results
Use automated static analysis tools, e.g., warnings on
program analysis tools
Use manual tests such as penetration testing, threat
modeling, and interactive tools to reach beyond auto
testing tools
Run program under low memory conditions, insufficient
privileges, interrupt a transaction or disable connectivity
before transaction completed.
Definition Matching
Whitelist
1.
A set of resource limits imposed on programs by the
operating system kernel (e.g. I/O bandwidth caps & disk
quotas).
2.
Uses a time-sensitive mark to prevent packet replay
(e.g. CAPTCHA)
3.
List of acceptable input
4.
A security mechanism for quarantining untrusted
running programs.
5.
Reject suspect input
Blacklist
Nonce
Jail
Sandbox
Environment
Definition Matching
Whitelist
1.
A set of resource limits imposed on programs by the
operating system kernel (e.g. I/O bandwidth caps & disk
quotas).
2.
Uses a time-sensitive mark to prevent packet replay
(e.g. CAPTCHA)
3.
List of acceptable input
4.
A security mechanism for quarantining untrusted
running programs.
5.
Reject suspect input
Blacklist
Nonce
Jail
Sandbox
Environment
Question
1.
2.
3.
4.
A third party inserts attack data into
another organization’s html response.
This is known as:
Cross-Site Scripting
Blacklist
Race Condition
Cleartext
Question
1.
2.
3.
4.
What technique would NOT be appropriate in
avoiding OS Command Injection?
Separate control information from data
information
Use library calls instead of external processes
Run code in “jail” or other sandbox environment
Use a hard-coded password to enable access
Question
1.
2.
3.
4.
Which of the following is true concerning web
servers?
Servers cannot retain web session state, and
thus the client must do it
The single best place to do input validation and
authentication is at the client-side
Using client as storage is safe if encryption and
integrity checking are used
The server can trust web input if it validates the
data in the web form
Question
1.
2.
3.
4.
The BEST way to ensure input validity at
the client is:
Nonce
Whitelist
Blacklist
Integrity Checking
Question
1.
2.
3.
4.
The BEST implementation of Access Control
would be:
Do not provide caches for sensitive data
Always use minimal possible permissions in
code, for as short of a time as possible
Avoid using cookies and hidden fields
Never provide an authorization above ‘guest’ to
web users
Question
1.
2.
3.
4.
SQL Injection is BEST protected against
by using:
Cleartext
Encryption and Integrity Checking
Sanitization
Clearly defined code such as UTF-8
Question
1.
2.
3.
4.
The main way to avoid replay between a
client and server is:
Integrity checking
Whitelist
Blacklist
Nonce
Question
1.
2.
3.
4.
An attack that could cause the MOST
problems includes:
Hard-coded password
Race condition
Denial of Service
Chatty error message
Question
1.
2.
3.
4.
The BEST way to ensure no message
modification occurs is:
Hashing
Whitelist
Blacklist
Encryption
Question
1.
2.
3.
4.
All of the following EXCEPT which answer can
result in invalid data AND break-in?
Non-random random number generator
Buffer overflow
Uninitialized variables resulting in error
messages
Race conditions