Software Security Basics

CY L. SOFTWARE SECURITY BASICS

By CY L. https://github.com/cyl337

Photo Credit: Yuri Samoilov CC BY 2.0

http://creativecommons.org/licenses/by-nc-sa/4.0/

https://www.flickr.com/photos/yusamoilov/13334048894

https://www.flickr.com/photos/yusamoilov/13334048894

https://creativecommons.org/licenses/by/2.0/

To provide a brief introduction on software security

and web attacks

To raise security awareness in program design and

implementation

OBJECTIVES OF THIS SHARING

By CY L. https://github.com/cyl337 2


1. Overview on Software Security

2. Common Web Attacks

3. Secure Programming Practice

AGENDA






AGENDA



Functionality concerns Correctness

e.g. Searching function should return results based

on user input

Security concerns Preventing Undesired Behaviour

e.g. Searching function should NOT reveal Admin

password

WHAT IS SOFTWARE SECURITY?



Stealing Information

Breach of Confidentiality

Modifying Information or functionality

Breach of Integrity

Denying Access

Breach of Availability

UNDESIRED BEHAVIOURS



In this session we will focus on

Reduce vulnerability caused by defects in design and implementation

Avoid web attack in particular

Other areas not covered

Low level attack (Buffer overflow)

Static Analysis and Symbolic Execution

Defensive measures like Anti-virus, Firewalls

Usability security like Authentication, Secure Browsing

SESSION’S FOCUS






AGENDA



Cross-Site Scripting (XSS)

SQL Injection

Cross-Site Request Forgery (CSRF)

COMMON WEB ATTACKS



COMMON WEB ATTACKS

Cross-Site Scripting

(XSS)



Subvert Same Origin Policy

Trick user’s browser into believing origin of malicious

script is trusted server

Malicious script executed with access privilege

granted to trusted server

CROSS-SITE SCRIPTING (XSS)




Browser

Attacker.com

Trusted.com

1. Inject

malicious script

4. Execute

malicious script

as though trusted

server meant us

to run it



Counter-measures

Validate user input before publish

Sanitizing

Filter out all scripts (e.g. <script>, <javascript>)

… but there are ways to circumvent

White List

Instead of full markup language support, use a

simple restricted subset, e.g. markdown




COMMON WEB ATTACKS

SQL Injection



Inject SQL statements into parameters of original

query statement

Programs confused input data as code and execute

malicious SQL statements

SQL INJECTION



SQL INJECTION

http://xkcd.com/327/



String sql =

"select * from user where

username='" + username +"' and

password='" + password + "'";

stmt = conn.createStatement();

rs = stmt.executeQuery(sql);

SQL INJECTION



SQL INJECTION

select * from user where

username='anyone' or 1=1;

-- ' and password='whocares';

select * from user where

username= 'anyone' or 1=1;

DROP TABLE Users;

-- ' and password='whocares';



Counter-measures

Validate user input

Whitelist

Blacklist

Remove special SQL characters (e.g. ‘ ; - \)

Escaping

Escape special SQL characters

SQL INJECTION



Counter-measures

Prepared Statement (Parameterized Queries)

String sql = "SELECT * FROM User WHERE userId = ? ";

PreparedStatement prepStmt =

conn.prepareStatement(selectStatement);

prepStmt.setString(1, userId);

ResultSet rs = prepStmt.executeQuery();

SQL INJECTION



Counter-measures

Limit privileges

Limit user’s access right per DB table

SQL INJECTION



COMMON WEB ATTACKS

Cross-Site Request Forgery

(CSRF)



URLs with side effects

http://bank.com/transfer?amount=99999&to=attacker

Users got tricked to visit the crafted link when

logged in

And make unintended request

CROSS-SITE REQUEST FORGERY (CSRF)




Browser

Attacker.com

bank.com

User logged on

bank.com

$$$



Counter-measures

Avoid URL with side effect

Check HTTP Referrer

Secretized link

Include a token as parameter in query string




More information on other common attacks:

https://www.owasp.org/index.php/Top_10_2013-

Top_10




https://www.owasp.org/index.php/Top_10_2013-Top_10






AGENDA



A very common source of vulnerability is that

program confused data with instruction

SECURE PROGRAMMING PRACTICE



Trust with Reluctance

Always validate external input

Eliminate input data which may be confused

as instruction




Client-side validation

Early feedback on user’s mistakes

Better user experience

But it can be circumvented, ALWAYS!

Server-side validation

Gate keeper

Should guard against any invalid input

It can NEVER be replaced by client-side validation,

NOT even partly




VARIOUS TYPES OF EXTERNAL INPUT

Form field

Query String

Hidden form field

Cookie

Header

AJAX



PRACTICE ON FORM PROCESSING

Servlet / controller /

Managed Bean

Backend

Handler /

Session Bean

External input External input




Problem

Backend expects untainted, trusted valid input


Managed Bean

Backend

Handler /

Session Bean

@tainted

External input

@tainted

External input




Better approach

– Validate external input and only pass validate data to

backend


Managed Bean

With

Validation

Backend

Handler /

Session Bean

@tainted

External input

@untainted

Validated input



Form VO – Untrusted

Backend DTO – Trusted

public String doSubmit() {

if (validate(formVo, request) == PASS) {

backendDto = composeDto(formVo,request);

BackendHandler.process(backendDto);

} else {

// Reject input

}




Software security concern preventing breach of

Confidentiality

Integrity

Availability

Some common web attack and countermeasures

XSS

SQL Injection

CSRF

Principle: Trust with reluctance

Always validate external input

SUMMARY



2013 Top 10 security risks | Open Web Application Security

Project (OWASP)


Software Security online course on Coursera

https://www.coursera.org/course/softwaresec

Badstore - ISO image for demonstrating web application

vulnerabilities

https://www.vulnhub.com/entry/badstore-123,41/

REFERENCE






https://www.coursera.org/course/softwaresec


