Transcript Icc13-old

Security in Application
& SDLC
Barkan Asaf
Nov, 2006
1
Application
Load
Balancer
Application
Client
App Server
Databases
Web Server
Proxy
Hardened OS
External Network
DMZ
Firewall
Firewall
Firewall
Network Layer
Application Layer
Security Perimeter
Internal Segment
Internal Segment
2
Confidential & Proprietary
Security Regulations
& Standards
3
Confidential & Proprietary
Vulnerability Stack & Security scanners
4
Confidential & Proprietary
Technical vs. Logical
Vulnerabilities
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
Confidential & Proprietary
5
Security Tollgates in
Software Development Life Cycle (SDLC)
Release Cycle
Product
Requirements
Functional
Design
Technical
Design
Implementation
Testing
Beta
Security Tollgates
Security
Requirements
Document
Architectural
Risk Analysis
Security
Testing
Secure Coding
6
Confidential & Proprietary
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
Counter measures
Use Application level validation that
includes:
• Strong data type
• Length
• Logical Boundaries
• Legal characters
• Correct Syntax
Confidential & Proprietary
7
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
8
Confidential & Proprietary
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 HTTP<->HTTPS
• 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)
9
Confidential & Proprietary
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
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
10
Confidential & Proprietary
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 buf[BUFSIZE];
gets(buf);
Counter measures
• Use interpreted languages as Java/Python 
• Validate your input boundaries and size before processing
11
Confidential & Proprietary
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
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
12
Confidential & Proprietary
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.
13
Confidential & Proprietary
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
14
Confidential & Proprietary
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
15
Confidential & Proprietary
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
16
Confidential & Proprietary
Summary
• Loose the naïve approach regard client’s 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
17
Confidential & Proprietary
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
18
Confidential & Proprietary
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 1=1 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
Confidential & Proprietary
19
Validation layers (Secure in depth)
Presentation
Business logic
Persistence
20
Confidential & Proprietary