Stored and Reflected XSS Attacks

Cross-Site Scripting (XSS) attacks occur when:
1. Data enters a Web application through an untrusted source, most frequently a web request.
2. The data is included in dynamic content that is sent to a web user without being validated for malicious code.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Damn Vulnerable Web App (DVWA) and The Top 10 Risks

Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.

The Top 10 Risks list compiled by the Open Web Application Security Project (OWASP) are:

1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Data Validation Testing, Denial of Service Testing, Web Services Testing, and AJAX Testing (from OWASP)

1. Data Validation Testing
The most common web application security weakness is the failure to properly validate input coming from the client or environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.

1.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)

We gonna tried <script>alert("hello world")</script>: http://www.akakom.ac.id/index.php?user=<script>alert("hello world")</script>, so the link directed to http://www.akakom.ac.id/index.php?user=%20script%3EALERT%20%20hello%20world%20%20%20%2Fscript%3E#31610346594256744308. The page seems not changed anything.

1.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)
Stored XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application.

Cookies and Session (on Web Browser)

What are session cookies used for?

Webpages have no memories. A user going from page to page will be treated by the website as a completely new visitor. Session cookies enable the website you are visiting to keep track of your movement from page to page so you don't get asked for the same information you've already given to the site. Cookies allow you to proceed through many pages of a site quickly and easily without having to authenticate or reprocess each new area you visit.

Session cookies allow users to be recognized within a website so any page changes or item or data selection you do is remembered from page to page. The most common example of this functionality is the shopping cart feature of any e-commerce site. When you visit one page of a catalog and select some items, the session cookie remembers your selection so your shopping cart will have the items you selected when you are ready to check out. Without session cookies, if you click CHECKOUT, the new page does not recognize your past activities on prior pages and your shopping cart will always be empty.

Session Management Testing, Authorization Testing, and Business Logic Testing (from OWASP)

1. SESSION MANAGEMENT TESTING
At the core of any web-based application is the way in which it maintains state and thereby controls user-interaction with the site. Session Management broadly covers all controls on a user from authentication to leaving the application. HTTP is a stateless protocol, meaning that web servers respond to client requests without linking them to each other. Even simple application logic requires a user's multiple requests to be associated with each other across a "session”. This necessitates third party solutions – through either Off-The-Shelf (OTS) middleware and web server solutions, or bespoke developer implementations. Most popular web application environments, such as ASP and PHP, provide developers with built-in session handling routines. Some kind of identification token will typically be issued, which will be referred to as a “Session ID” or Cookie.

Configuration Management Testing and Authentication Testing (from OWASP)

1. Configuration Management Testing
Often analysis of the infrastructure and topology architecture can reveal a great deal about a web application. Information such as source code, HTTP methods permitted, administrative functionality, authentication methods, and infrastructural configurations can be obtained.

2. Authentication Testing
Authentication is the act of estabilishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. In computer security, authentication is the process of attempting to verify the digital of the sender of a communication.

Securing Communication Data (Part 1 - GnuPG)

GPG is the main program for the GnuPG system. From The GNU Privacy Handbook: "GnuPG uses public-key cryptography so that users may communicate securely. In a public-key system, each user has a pair of keys consisting of a private key and a public key. A user's private key is kept secret; it need never be revealed. The public key may be given to anyone with whom the user wants to communicate."

With Backtrack 5, gpg already installed when we used it. Maybe gpg just used with konsole/terminal, for GUI (Graphical User Interface) -one of the tools- we can used kleopatra.