10 – 12 april 2005 riyadh, saudi arabia. web application security fundamentals murat lostar...

10 – 12 APRIL 2005 Riyadh, Saudi Arabia10 – 12 APRIL 2005 Riyadh, Saudi Arabia

Web Application Security FundamentalsWeb Application Security Fundamentals

Murat LostarInformation Security Consultant

“When we face a choice between adding new features and resolving security issues, we need to choose security.

Our products should emphasize security right out of the box”

Bill Gates

CIA ConceptCIA Concept

ConfidentialityInformation must be protected from unauthorized disclosure

IntegrityInformation must be protected from unauthorized modification

AvailabilityInformation must be available when the users need it

The goal of an attackThe goal of an attack

Steal data

Blackmail

Beachhead for other attacks

Bragging rights

Vandalism

Demonstrate vulnerability/satisfy curiosity

Damage company reputation

Designing Secure SystemsDesigning Secure Systems


How much security does a web application require?

Zero risk is not practical

There are usually multiple ways to mitigate risk

Don’t spend $ 1.000.000 to protect $ 0,1

Security is almost always overhead, either in cost or performance


Common Security Mistakes

Security Principles

Security Design by Threat Modeling - STRIDE

Security Techniques

A Cornucopia of Threats and Solutions

Common Security MistakesCommon Security Mistakes

Not designing applications with security in mind.

Adding security to the application as an afterthought.

This can be expensive than you think.

Adding security later,

Can change the way the features have been implemented

Can change the application interface

Can break the previously written code

Why these mistakes are made?Why these mistakes are made?

Security is boring

Security disables some functionality.

Security is difficult to measure.

Security is not the interest of the designers and developers creating the product.

Security PrinciplesSecurity Principles

Establish a Security Process

If you don’t define a process for designing, coding, testing, deploying and fixing systems in a secure manner, it’s very likely that you will spend a huge amount of time fixing security bugs.

Consider Security as a Product Feature

Build and review the development plan.


Define the Product Security Goals

Who is the audience?

What does security mean to the audience?

Where will the application run?

What are you attempting to protect?

Who will manage the application?

What are the communication needs of the product?

What security infrastructure services do the OS and the environment already provide?


Learn from Mistakes – Every bug is a learning opportunity

How did the security error occur?

Is the same error replicated in other areas of code?

How could we have prevented this code from occurring?

How do we make sure this kind of error does not happen in the future?

Use Least PrivilegeWhat resources must your application access?

What special tasks must your application perform?


Use Compartmentalization (separation of privileges)Separation between users, processes, data, and networks helps contain problems if they occur.

Give the

Use Defense in DepthDon’t rely on other systems to protect you

At some stage you (your software) have to defend yourself.

Implement a “default deny” stance


Assume External Systems Are Insecure

Until proved otherwise, all external stimuli have the potential to be an attack.

Plan on Failure

Bugs happen

Make security contingency plan

Fail to a Secure Mode

The application has not disclosed any data that would not be disclosed ordinarily, the data still can not be tampered with, ...

Do not issue huge swaths of information explaining why the error occured. Give the user a little bit of information.

Here is an example:

Security Principles – Code ExampleSecurity Principles – Code Example

...

DWORD dwRet = IsAccessAllowed(...)

if (dwRet == ERROR_ACCESS_DENIED) {

// Security check failed.

// Inform user that access id denied.

} else {

// Security check OK.

// Perform task.

}

....

Security Principles – Code ExampleSecurity Principles – Code Example

...

DWORD dwRet = IsAccessAllowed(...)

if (dwRet == NO_ERROR) {

// Security check OK.

// Perform task.

} else {

// Security check failed.

// Inform user that access id denied.

}

....


Employ Secure DefaultsIf a feature is not running, it cannot be vulnerable to attack

Another reason for not enabling features by default is Performance.

Backward Compatibility Issue?Be ready to face many upgrade and backward compatibility issues if you change critical features (for security reasons.)

The weak version of the protocol lives forever.

Security Features = Secure Features ???Security features do not necessarily make for a secure application.


Never Depend on Security Through Obscurity

Always assume that an attacker knows everything you know

Validate input and output

User input and output to and from the system is the route for malicious payloads into or out of the system

Allow only explicitly defined characteristics and drop all other data


Keep it simple

Often the most effective security is the simples security

If the steps to secure a function or module of the application are too complex, they probably won’t be followed

Complex code is hard to understand, makes maintenance error-prone


Use and reuse trusted components

When someone else has proven they got it right, take advantage of it

Beneficial from both a resource and security perspective

Only as secure as the weakest link

Attackers will find the weakest point and attempt to exploit it

Don’t leave all the locks on the front door and leave the back door swinging open

Security Principles – Three Final PointsSecurity Principles – Three Final Points

If you find a security bug, fix it and go looking for similar issues in other parts of the code.

If you find a security bug, make the fix as close as possible to the location of the vulnerability.

If there is a fundamental reason why a security flaw exists, fix the root of the problem. Don’t patch it over.

An ExampleAn Example

WebBrowser

WebServer

App. Comp.

DBServer

Authentication Data

Web Pages

Application Data

Audit Data

LDAP

HTTP DCOM SQL Over Sockets


Threat 1: A malicious user can view or tamper with personal data en route from the Web server to the client or from the client to the Web server

Threat 2: A malicious user can view or tamper with personal data en route from the Web server to the application component or from the component to the Web server


Threat 3: A malicious user can access or tamper with the personal data directly in the database

Threat 4: A malicious user can view LDAP Authentication packets and learn how to reply to them so that he can act “on behalf of” the user


Threat 5: A malicious user can deface or redirect the Web server by changing one or more Web pages

Threat 6: An attacker can deny access to the database server by flooding it with TCP/IP packets


Threat 7: An attacker can delete or modify the audit logs

Threat 8: An attacker can place his own Web server on the network after killing the original server with a distributed DoS attack.

OWASP.orgOWASP.org

Open Web Application Security Project

Top-Ten Web Security Vulnerabilities

Top-Ten Web Security Vulnerabilities Top-Ten Web Security Vulnerabilities

1 Unvalidated Input

2 Broken Access Control

3 Broken Authentication and Session Management

4 Cross Site Scripting (XSS) Flaws

5 Buffer Overflows

6 Injection Flaws

7 Improper Error Handling

8 Insecure Storage

9 Denial of Service

10 Insecure Configuration Management

#10: Web/App Server Misconfiguration#10: Web/App Server Misconfiguration

Tension between “work out of the box” and “use only what you need”

Developers ≠ web masters

ExamplesUnpatched security flaws

Misconfigurations that allow directory traversal

Administrative services accessible

Default accounts/passwords

CountermeasuresCreate and use hardening guides

Turn off all unused services

Set up and audit roles, permissions, and accounts

Set up logging and alerts