The Security Depth is inversely proportional to the Weakest link in an n – Tier Architecture
The Below Diagram shows a n Tier Architecture. To explain the data traversing between the layers, the diagram shows that data travels from presentation Layer to Business Logic Layer to Data Access layer. Our minds usually sees what it’s trained to see.
http://en.wikipedia.org/wiki/Image:Overview_of_a_three-tier_application.png

From the above diagram it’s obvious that if Security is heavy and 100% in Presentation Layer, then no data can traverse to next Layer and hence the system is absolutely Secure. Alternatively if the Database has heavy Security protocols, though Request gets passed from Business Layer it gets restricted in Database Layer. Hence the Data Traversing is Serial.
This is absolutely true and our minds are trained to think that the same serial access is provided to Security. Data needs to pass through 3 doors, and hence, “Security in one door is good enough.”
Alas when it come Security it behaves likes 3 parallel doors and not 3 Serial Doors.
1) Weak Presentation Layer but strong Business and Database layers – Let’s assume that Presentation Layer allows to User to mask himself as Administrator, then the User enters through the remaining 2 doors as Admin. E.g. URL sending userID with base64 encryption. Encrypt Admin UserName with base 64 and send it across to gain access. Pretty simple, but happening in most projects
2) Weak Business Layer – Most applications use IIS if MS technology is used. In IIS for sites, we usually use Network Authentication or we Give Application Pool with Standard User. Most Cases this Standard User is Super user to let communication happen via WebServices. If user gets restricted in Presentation Layer but masks in Application Layer, the layer gives complete Access to DB
3) Weak DB Layer – If no Logic is employed in DB or in Sprocs to check Authentication but give data for any Valid request, you can still sneak information.
Thus when it comes to Security it’s not 3 Serial Doors but 3 Parallel Doors. J

Note for the Week: Never trust Client Side Request or Web request.

Cross Site Scripting
Cross Site Scripting attacks (a form of content-injection attack) differs from the many other attack methods covered in this article in that it affects the client-side of the application (ie. the user's browser). Cross Site Scripting (XSS) occurs wherever a developer incorrectly allows a user to manipulate HTML output from the application - this may be in the result of a search query, or any other output from the application where the user's input is displayed back to the user without any stripping of HTML content.
A simple example of XSS can be seen in the following URL:
http://server.example.com/browse.cfm?categoryID=1&name=Books
In this example the content of the 'name' parameter is displayed on the returned page. A user could submit the following request:
http://server.example.com/browse.cfm?categoryID=1&name=<h1>Books
If the characters < > are not being correctly stripped or escaped by this application, the "<h1>" would be returned within the page and would be parsed by the browser as valid html. A better example would be as follows:
http://server.example.com/browse.cfm?categoryID=1&name=<script>alert(document.cookie);</script>.
In this case, we have managed to inject Javascript into the resulting page. The relevant cookie (if any) for this session would be displayed in a popup box upon submitting this request.
This can be abused in a number of ways, depending on the intentions of the attacker. A short piece of Javascript to submit a user's cookie to an arbitrary site could be placed into this URL. The request could then be hex-encoded and sent to another user, in the hope that they open the URL. Upon clicking the trusted link, the user's cookie would be submitted to the external site. If the original site relies on cookies alone for authentication, the user's account would be compromised. We will be covering cookies in more detail in part three of this series.
In most cases, XSS would only be attempted from a reputable or widely-used site, as a user is more likely to click on a long, encoded URL if the server domain name is trusted. This kind of attack does not allow for any access to the client beyond that of the affected domain (in the user's browser security settings).
For more details on Cross-Site scripting and it's potential for abuse, please refer to the CGISecurity XSS FAQ at http://www.cgisecurity.com/articles/xss-faq.shtml.

Security Testing - Overview
Security Testing is quite a vast field. I had a different vision before I attended a training on Security, but the entire concept changed after the training. Visioning myself as a cool hacker (Just to note Hackers are people who want to improve Security by pointing flaws in code which have potential loopholes for crackers or hijackers to enter) after watching Die Hard 4, I had different opinion. I assumed it to be a pretty straight forward job for guys who are geeks. Alas hacking is not so simple, but extremely challenging and can be very frustrating at times.

[New] - Security Checklist and Report

Hacking is involved in 4 stages
1) Reconnaissance - To completely understand the application
2) Foot Printing Target - To create a sample application for Cracking
3) Discovering Vulnerabilities
4) hacking, Cracking or attacking.
Thus Security Testing also contains the same 4 steps except the last one. The last step would be replaced with
4) Providing Security Tips to avoid vulnerabilities

Hacking can happen due to these Major Reason
1) Weakness in Custom Application
2) Architectural Flaws
3) Flawed Design Configurations and Code

5 Classes of Code Vulnerability
1) Security Related Information
a) Weak or Non Standard Cryptography
b) Non Secure N/w Communications
c) Application Configuration Vulnerabilities
d) Access Control Vulnerabilities
i) Unprotected Database and File System Use
ii) Dynamic Code Vulnerabilities
iii) Native Code Loading
iv) Data Storage Vulnerabilities
v) Authentication Errors
Access to page through URL where no access is permitted by caching in Local M/C or Server
2) Input / Output Validation and Encoding Errors
a) SQL Injection
b) Cross Site Scripting – Unsuspecting Users to execute or access malicious code
i) Stored Attacks
ii) Reflected Attacks
Stealing Session and disclosure of information
Can be avoided by “HTML Entity Encoded”
c) OS Injection
d) Custom Cookie / Hidden Field Validation
3) Error Handling and logging Vulnerabilities
a) Insecure Error Handling
b) Insecure or Inadequate Logging
4) Insecure Components – Malicious Code
a) Unsafe Native Methods – Accessing System Resources Directly and not through Interfaces which pose threat id unsafe coding standards are followed
b) Unsupported Methods
5) Coding Errors
a) Buffer Overflow Vulnerabilities
b) Format String Vulnerabilities
c) Denial of Service Errors
d) Privilege Escalation Errors
e) Race Conditions
"The Path to a Secure Application: A Source Code Security Review Checklist"
Security in SAAS becomes of critical importance as then all details are now open to anybody over the internet. Thus the traditional methodology of speed, feature set and ease of use are not supplemented with Security and very soon Security will be of Highest importance.

The methodologies of Hacking are
1) Cross Site Scripting - 21% of hacking happens here
2) Injection Flaws - Traditional SQL injection
3) Uploading Malicious File
4) Insecure Direct Object Reference
5) Information Leakage - 73% of hacking happens here
6) Insecure Cryptography
7) Insecure Storage
8) Insecure Communication
9) Failure to restrict URL Access
10)Cross Site Request Forgery
11)Hidden form elements

Some Common Terminologies in the World of Security Testing
1) Phishing
2) Cross Site Scripting
3) SQL injection
4) Profiling
5) Same Origin Policy

Reasons for Hacking
1) For Fame to prove the world that you are the BEST
2) To Steal sensitive Information
3) To Deface a site, company
4) To plant Malicious Software for Gains