– Understand Software Security (sec = short form)
– Understand security features in web browsers
– List common attacks
– For each attack, understand the attack, it’s technique and how to mitigate

[Part 1 Intro to Soft Sec.]

– More code increases chance of bugs
– Threats can come from inside or outside the company

– Security and privacy expectations are implicit
– Software Security is a relatively young field
– Software failure is a real and pervasive problem
– We need to build software that is secure and can be secured
– The problem with penetration testing is that it does not provide a solution to the problems it discovers

Two Broad Classes of Security Defects

– Bugs happen in Implementation
– Flaws happen at Architecture Design
– Bugs/Flaws in software is 50/50

– Bugs fixed in code
– Flaws fixed in Architecture Risk Analysis
– Defect is both implementation and design vulnerability

Trinity of Trouble
– Connectivity: Everything is connected to the internet
– Complexity: Simple UX ironically leads to more complicated code
– Extensibility: Software must be flexible enough to work with code that hasn’t been made yet. Client-server model is the simplest attack pattern to exploit. As a server-side developer, you must ensure the system can defend itself against misbehaving clients.

Impacts of Software Failure
– Financial loss
– Data loss
– Performance loss
– Brand rep loss
– Customer trust loss
– Compliance failure

[Part 2 – The browser sec model]

Same origin policy: Prevent different domains from interacting with each other

Web Browsers and Web Applications
– Same origin policy: Permits scripts running on pages originated from the same site or origin; Client-side is responsible for enforcing strict separation
– Exclusions: HTML Img, Scripts, and Style sheets
– The browser security model prevents access of content from different origins
– DOM: Document Object Model: Used to represent HTML and XML
– Web browsers use DOM optionally but for JavaScript to execute, it is required
– Mashups: Getting data from multiple origins and having them interact with each other violates the Same Origin

[Part 3 – Attack & Defense Vulnerability Discovery, Prevention]

ATTACK #1: XSS – Cross Site Scripting

Bypass the Same Origin Policy. There are two types:

1) Persistent: Stored on the server-side, downloaded when client downloads compramised web page
2) Reflected: User input has the malicious script sent to the application, it’s executed on the server, the results are sent back to the browser

Examples of reflected:
– Cookie session hijack
– Re-writing HTML
– Impersonating requests as a legit user
– Faking a login/password screen
– Performing port scan on LAN

– Because the script comes from a trusted web server, it does not violate the Same Origin Policy
– Same origin policy limits HTML content but does not limit script blocks, images and CSS. It can load from another source but it limits what gets executed. This mean malicious scripts get downloaded at the same time the DOM is created.
– Man in the middle attack: Relay I/O the user sends and receives from a compromised site.

Protecting Against XSS
– Encode outputs: Select an encoding method that does not produce control sequences; HTML encoding for HTML output;
< is a “<" symbol; URL encoding for log files; This forces content to be treated like plain text instead of runnable code - Constrain inputs: perform regEx and parsers to check syntax on the server side - Safely store and process data using safe methods Mitigation & Remediation
– Client-side validation can be easily by passed by an attacker
– Server-side must reject bad input rather than process it
– Java: Use jTidy as an encoding library

How to Test for XSS
– Check if input validation is being done on the server
– Check if output encoding is being done on the server
– Check if malicious XSS code is between HTML tags, inside HTML attributes, or in


– XSS in HTML tag check: Embed JavaScript alerts (i.e. displaying your session ID) in your server-side code to check for vulnerabilities; if the alert is displayed properly, then you are not doing any output encoding. If it is done properly, the JS alert script will appear as plain text
– XSS in HTML attribute check: Check for presence of malicious code store in attributes/callbacks like onLoad,

onError, onMouseOver
– Rostering: Use a white list of acceptable location to reference remote resources i.e.

http://myWebsite.com/balloon.jpg vs http://atacker.com/ballon.jpg
– XSS in script tags: Ensure the content you have in the


tags is the one you wrote

ATTACK #2: SQL Injection

1) SQL Concatenation: Ability to assemble to a dynamic SQL query with OR, SELECT, JOIN, UPDATE
2) Stored procedure w/ runtime variable: Inject un-intended parameters
3) Prepared Query object (name-value pairs) where the value references run-time server-variable i.e. currentDate()

– SQL Injections cause apps to return different data to the attacker than what should normally be returned
– Static Analysis tools: Scan code for SQL Queries that combine both user and hard coded defined input;
– General approach to discovering vulnerabilities is to add tautological parameter values and examine the results
– One example for a username and password would be ” and ‘1=1–‘
– Submit inputs via POST and GET, Cookie Values and Header Values

Check for input-based vulnerabilities:

– Integer:


If this executes as 123, it is being interpreted as code instead of as an integer

– String:


If this executes as ABC, it is being interpreted as code instead of as a string

– Errors:


If this throws an error, it’s because it’s being interpreted as code

Information leaking through back doors: Egress Connections; Timing Attacks

ATTACK #3: Header Manipulation

– Attackers modify the HTTP response coming from a trusted web app
– Attackers send HTTP request that forces server to send two HTTP responses; attackers control the 2nd response
– The headers in the response separate the original header using %0d%0a which is the URL-encoded equivalent of Carriage Return Line Feed characters


and allow attackers to define a new http response containing a malicious payload. The client will make only one request but it will be sent two. The first one ends abruptly while the second one is malicious.
– Header manipulation is a great way to launch XSS.
– Solution #1: URL encode strings before they become a part of HTTP response headers
– Solution #2: Validate user input for

CRLF, \r\n, %0d%0a

, any other funny encoding

ATTACK #4: System Information Leak

– Attackers can learn about a system when it provides too much information or information that was unintended.
– Examples: Verbose error messages tip off what an attacker can and cannot do; Never display a stack trace to a user, although useless to a typical user, it would provide insight to an attacker (reverse engineering)

How to Test for information leaks:
– SQL/XPath injection; testing for valid username using the forgot password feature
– Data-type confusion: Pass an invalid date to get access to a stack trace
– XSS on the common error page

– try/catch blocks – handle the exceptions instead of display them
– redirect users to a relevant error page, i.e. NoSuchPage.html when a 404 happens

ATTACK #5: Path Manipulation/Directory Traversal

– Exposed File I/O operations allow for unauthorized CRUD calls on the system’s resources
– Example: http://foo.com/../../../../etc/passwd

String downloadFileName = request.getParameter(“filename”);
File file = new File(“c:\\tomcat\\webapps\\myapp\\imguploads\\” + downloadFileName;

On the user-interface, if we can specify the value of what would be downloadFileName variable, this would be allowed


– Testing: Look for areas in the code that take in a string representing a file path; use “../../foo.txt” and add

“../” to go beyond the application directory

– Solution #1: RegEx only acceptable characters
– Solution #2: chroot directory permissions to define where can read and who can write

ATTACK #6: Cross-Site Request Forgery (CSRF)

Piggyback on victim’s sessionID so that an attacker can make legit requests on their behalf unbeknownst to them

– Exploit: Attackers create an

<img>, hidden <form>, <IFRAME>

or Javascript that calls actions in the background
– Example:

<img src="http://bank.com/transfer?to=attacker&amt=200"/>

Note how this is not a valid bitmap to display so nothing will show and it will work because it is being done on a valid user session.
– How to test: Use HTTP proxy software like Fiddler; inspect the request and response
– Prevention: Pair session ID’s with a security token; the unique random security token is store on the server and it’s store as a hidden parameter in the HTML form sent to the user

ATTACK #7: Hidden Field Manipulation

– Attackers change hidden or disabled form fields on a form
– Example #1: A disabled button is sent to the client; attackers enable the button locally and are able to click on the button thus executing the action
– Example #2: Instead of manipulating the HTML, they can just modify the request parameters to do what the button click would have done using tools like BurpProxy
– If attackers can manipulate the requests, they can control the application logic
– How to test #1: Use the same software proxy tools to intercept and change hidden field parameters on requests and observe the responses. If an exception is thrown
– How to test #1: Use browser tools like Firefox’s Web Developer plugin to enable form fields to see all hidden fields

– Solution #1: Input validation on the client side
– Solution #2: Resource permission check on the server-side to validate the current logged in user is allowed to access said resource

ATTACK #8: Cookie Security

Cookies are name-value stores to track userid, sessionid, and preferences; Attackers can then use this information to impersonate the user
– Attackers can transfer and view cookies using insecure protocols
– Attackers can access cookies if it is shared among multiple applications and the attacker is in control of one of those applications
– The longer a cookie persists, the longer an attacker has time to access it
– Allowing cookies to be accessed by JavaScript can be harmful if the JavaScript did not originate from the original application (i.e. XSS)
– Solution: Some browsers support HTTPOnly flag which prevent client-side JavaScript from reading it’s cookies
– How to test #1: 1) Go to the website you want to test 2) type


3) if you see an alert popup with name-value pairs, it means the HTTPOnly flag is not set
– How to test #2: Use HTTP proxy to see if the HTTP header cookie config like secure flag, domain, path and expiration
– How to test #3: Static analysis tools to search the code base for any areas where there is a Cookie object instantiated; there you can view what flags have been set
– Solution #1: Setting the secure flag on cookie so that it can only be sent over HTTPS
– Solution #2: Expire cookies to shortest time possible
– Solution #3: Set domain and path to be only used on your application; this prevents it from being shared with other apps thus reducing the attack surface
– Solution #4: Don’t use cross application cookies; less secure applications may have access to sensitive information stored on the shared cookie
– Solution #5: Set the HTTPOnly flag to true

ATTACK #9: Session and State Management

HTTP is stateless. Every request is discrete. The only way it knows any two requests are related is via a common sessionID. Application server software automates the creation of sessionID’s to be un-guessable, non-colliding, and exclusive for only session management (meaning don’t use this string for any other purpose).

Exploit #1: SessionID Theft can be done through XSS

– Malicious cross-site JavaScript can access the cookie i.e. alert(document.cookie); instead of displaying in a browser, the cookie information is relayed to a website under the control of the attacker. The attacker then sets their own browser’s request to the same sessionID and beings to impersonate the victim’s requests

Exploit #2: Man in the middle attack

– Attackers look at the un-encrypted network traffic and look for session Id’s in the HTTP requests

Exploit #3; Brute force prediction

– If the application is creating session Id’s based off a pattern (i.e. sequentially), it is easy for attackers to predict and create their own sessionID
– If the range of possible session Id’s is small, it can be predicted using basic math and script

Exploit #4: Session fixation; attackers define the SessionID and the server treats it as legit

– Attacker request from the application server an arbitrary sessionID
– Attacker then presents the victim with a web link to the application’s login page with the known sessionID
– Victim enters username and password with the known sessionID
– Application authenticates the user but does not overwrite the known sessionID with a new sessionID
– Attacker is now in possession of a sessionID that has been authenticated

Solution #1: Expire cookies which store session Id’s
Solution #2: On logout or on time out, application server must invalidate sessionID
Solution #3: Application server should ignore session Id’s stored in variables on GET and POST requests
Solution #4: Cookies should have random changing token
Solution #5: Encrypt network traffic using SSL/TLS to prevent man in the middle
Solution #6: Application logic should only associate users with session ID’s after authentication, not before
Solution #7: Session Id’s before authentication should be considered invalid by the application
Solution #8: When a session ID is created, it should be mapped to an IP address. May not work in environment with load balancers where IP addresses may not
Solution #9: For extra sensitive transactions (i.e $), have the user re-authenticate
Solution #10: Application server should only accept sessionID’s created by that application server
Solution #11: Regenerate a sesionID after login
Solution #12: On cookies that contain the sessionID, set the secure attribute making the SSL/TLS mandatory for transmission
Solution #13: Use large random IDs to make them less predictable
Solution #13: Reduce dependence on persistent cookies

ATTACK #10 Weak Access Controls

Attackers are able to perform operations outside of what a typical user is expected to perform.
– Horizontal access is when an attacker can see the data of others in the same role
– Vertical access is when an attacker is able to access behaviors and data outside of their role i.e. Employee role accessing administrator functions

How to test #1: Changing the query string (Horizontal access)

http://site.com/confirmation.jsp?refNo=123 is your own

http://site.com/confirmation.jsp?refNo=456 is someone else’s data

How to test #2: Changing the URL


How to test #3: Parameter Tampering – In REST operations, delete and update operations can put in a arbitrary record ID to artifacts they should not have access (Horizontal access)

Hot to test #4: Parameter Tampering – When they access an application as an admin (or monitor the transactions of admin), the request and response is recorded and studied. Then the attacker will attempt to perform the same actions as a lower privileged user.

Solution: Weak access controls are architectural flaws; Implement a white list of users (Entitlements) to dictate what data and behaviors a user can possess; Make the access permissions as close to the object as possible i.e. don’t make global entitlements.


Google+ Comments