Security in Application

1
Security in Application SDLC

• Barkan Asaf
• Nov, 2006

2
Security Perimeter
Application
Load Balancer
App Server
Application Client
Application Layer
Databases
Web Server
Proxy
Hardened OS
Network Layer
Firewall
Firewall
Firewall
External Network
Internal Segment
DMZ
Internal Segment
3
Security Regulations Standards
"70 of today's successful hacks involve Web
Application attacks "
SPI Dynamics
4
Vulnerability Stack Security scanners
Web Application Security scanner
Network level Security scanner
5
Technical vs. LogicalVulnerabilities

• Logical Flaws
• Security vulnerabilities that arise with some
  contextual logic in application.
• Example
• Multi step procedure that can be bypassed with
  direct invocation

• Technical Vulnerability
• Security vulnerabilities that can be discovered
  without any contextual logic
• Examples
• HTML Injection
• SQL Injection

• Web Application scanners limitations/challenges
• Session state management -
• Script parsing
• Logical flows
• Custom URLs
• Privilege escalation
• False negative/positive

Technical vs. Logical Vulnerabilities at WhiteHat
6
Security Tollgates in Software Development Life
Cycle (SDLC)
Product Requirements
Functional Design
Technical Design
Implementation
Testing
Beta
Security Tollgates
Security Requirements Document
Architectural Risk Analysis
Security Testing
Secure Coding
7
Unvalidated Input (A1)
Description HTTP inputs into the application are
not validated. Include URL, Headers, query
strings, cookies, form fields, hidden fields.
Leads to almost all web application
vulnerabilities.
Threats Client-side Attacks (3), Command
Execution (4), Denial of Service (6.2)
Demonstration
Validation layers

• Counter measures
• Use Application level validation that includes
• Strong data type
• Length
• Logical Boundaries
• Legal characters
• Correct Syntax

8
Broken Access Control (A2)
Description Authorization boundaries in code are
broken or not properly enforced.
Threats Credential/Session prediction (2.1),
Insufficient Authorization (2.3) Insufficient
process validation (6.4)

• Counter measures
• Robust authorization management
• Do not trust client side tokens for
  authorization
• Authorize all requests except anonymous objects
• Block resource enumeration and Forced Browsing
  in application

9
Broken Authentication Session Management (A3)
Description A weak implementation of
Authentication framework or unsecure Session
management.
Threats Brute Force (1.1), Insufficient
Authentication (1.2), Insufficient session
expiration (2.3), Session fixation session (2.4),
Session prediction (2.1)
Demonstration

• Counter measures
• Use Random GUID as session indication
• Assign session id only after authentication
• Assign new session id when change from
  HTTPlt-gtHTTPS
• Correlate session indication with valid session
  object in application
• Use standard and robust Password policy
  enforcement
• Use standard and robust Lockout policy
  enforcement
• Do not trust client to send session state
  (session GUID only)

10
Cross Site Scripting (A4)
Description Attacker is using a vulnerable web
application into sending unintentionally a user
(Victim) a malicious active script that will be
executed on its browser and breach his security
framework.
Threats Client-side attacks (3)
Demonstration
Demonstration
XSS Demo

• Counter measures
• Use Application level validation that will
  either negatively or positively validate all
• inputs coming from untrusted clients.
• Use HTML encoding centrally in presentation layer

11
Buffer Overflows (A5)

• Description
• The attacker sends data to a program, which it
  stores in an undersized stack buffer.
• The result is that a either corrupted or
  malicious code is executed.
• Buffer overflow vulnerabilities typically occur
  in code that
• Relies on external data to control its behavior
• Depends upon external properties of the data
• Is so complex that a programmer cannot
  accurately predict its behavior

Threats Buffer overflow (4.1)
Code Example char bufBUFSIZE gets(buf)

• Counter measures
• Use interpreted languages as Java/Python ?
• Validate your input boundaries and size before
  processing

12
Injection Flaws (A6)
Description Attacker is using Injection flaws to
relay malicious code through a web application to
another System. The code is executed on behalf of
the web application.
Threats Command execution (4), Denial of Service
(6.2)
Example
SQL Injection - Code example

• Counter measures
• Use Application level validation that will
  either negatively or positively validate all
• inputs coming from untrusted clients.
• Use prepared statements and set each parameter
  before use in query

13
Improper Error Handling (A7)
Description Improper handling of errors in
application can result with the application
sending the attacker Error messages that reveal
implementation/architecture/components
information he should not know.
Threats Information leakage (5.2)

• Example
• throw SQL exceptions back to client
• throw stack trace on Web service exceptions
• throw Application server stack trace back to
  client

• Counter measures
• Catch all exceptions in server side never
  throw exception to client
• Handle all errors in back end
• Do not send the user excessive information that
  is not required as Platform architecture
• ports in use , components in use and more.

14
Insecure Storage (A8)
Description Improper usage/implementation of
cryptographic in code application.
Examples Saving private key of SSL server on File
system as clear text Saving DB connection object
as clear text on file system Failure to encrypt
critical data Poor sources of randomness Poor
choice of algorithm Attempting to invent a new
encryption algorithm Failure to include support
for encryption key changes
Threats Information leakage (5.2), Insufficient
Authentication (1.2)

• Counter measures
• Use well known and proven cryptographic
• Choose a suited algorithm according to
  security/performance trade-off
• Make secrets in memory not serialized
• Make keys replaceable and configurable by size
  if possible
• Encrypt all private/confidential credentials

15
Denial Of Service (A9)
Description All actions or procedures in
application that will make it unusable. Network
level attacks are not Included in here.
Threats Denial of Service (6.2)

• Example
• Resource starvation when all concurrent users
  are used by zombies
• HTML persistence injection causes DoS to the
  application main page

• Counter measures
• Use well known and proven cryptographic
• Choose a suited algorithm according to
  security/performance trade-off
• Make secrets in memory not serialized
• Make keys replaceable and configurable by size
  if possible
• Encrypt all private/confidential credentials

16
Insecure Configuration Management (A10)
Description Insecure usage of servers/components
configuration. Mostly out of the box settings are
not secure.

• Examples
• Unpatched security flaws in the server software
• Web server Misconfigurations (directory
  listing/traversal enabled)
• Unnecessary default, backup, or sample files
• Improper file and directory permissions
• Unnecessary services enabled
• Default accounts with their default passwords
• Administrative or debugging functions that are
  enabled or accessible
• Overly informative error messages (more details
  in the error handling section)
• Unsecre usage of certificates

Threats Insufficient Authentication (1.2),
Insufficient authorization (2.2), SSI Injection
(4.6), Directory indexing (5.1), Information
leakage (5.2), Path traversal (5.3), Predictable
Recourse Location (5.4), Abuse of Functionality
(6.1)

• Counter measures
• make hardening procedure to infrastructure
  before shipping

17
Summary

• Loose the naïve approach regard clients
  behavior

• Validate all inputs from untrusted clients

• No Such thing as Security in client side

• Use standard security solutions/configuration

• Make sure the client gets only the responses he
  needs

• Remove legacy/unnecessary resources from
  production app

18
Cross Site Scripting (XSS)
The script, sent by the attacked client to the
server was then received again by the client, now
with the proper security context, and was able to
send the cookie to the attacker
A4
19
SQL Injection Code example
By passing Login logic using SQL Injection
flaw SQLQuery "SELECT Username FROM Users WHERE
Username " strUsername " AND Password
" strPassword "" strAuthCheck
GetQueryResult(SQLQuery) If strAuthCheck ""
boolAuthenticated False Else
boolAuthenticated True End If Explanation If
Username or 11 this will be evaluated to true
always and the SQLQuery will be resolved to true
Returning the first record in Users table and
bypassing the login logic
Using UNION to concatenate data to flawed query
SELECT FirstName, LastName, Title FROM Employees
WHERE City UNION ALL SELECT OtherField
FROM OtherTable WHERE Explanation City
will return null from DB and the only record
sets returned From DB will be from the new query
A6
20
Validation layers (Secure in depth)
Web related issues
Logic boundries
Persistence breaches
A1