XXS Exploits via AJAX

The next exercise for the XXS exploit modal is stored XXS via AJAX. Ajax is a client-side script that communicates to and from a server/database without the need for a postback or a complete page refresh. Ajax allows a web programmer to transfer data without needing to refresh an entire page. Google Maps, YouTube, and Facebook all use Ajax. Gruyere uses ajax to send post information to the view using this code: _feed(( { "private_snippet": "" ,"cheddar": "Gruyere is the cheesiest application on the web." ,"brie": "Brie is the queen of the cheeses!!!" } )). Not having a lot of experience with AJAX or its syntax it was hard for me to formulate different posts to get stored XXS. Even after checking the first and second hints. The final result makes sense, but without knowing the syntax of AJAX it would be difficult to exploit. I will continue to look over the basics of Ajax before starting on the next exercise of reflected XXS using AJAX. 

I am going to focus my attention on Google’s Gruyere for the rest of the semester. I continued with the XXS section and started with stored XXS via a HTML attribute. Stored XSS is any hacker script being run on a later page by it being saved and accessed later. In this exercise it has you try to use stored XSS by exploiting the profile color input box.

After going through the HTML source code in the profile page I found that the color is rendered as style='color:color'. Seeing this I knew I had to break out of the style statement by adding a ‘ in front of my script in the text field.

 I went back to the source code to see how my script was stored after placing the script in the textbox.

My script was altered because the html page runs a python script that removes all javascript tags within user input divs to keep XXS from happening. After several different attempts I finally found a script call that worked after looking into the second hint that google provides.

As I move through these exercises I keep finding different aspects of web programming I already know being used in weird ways to break a web app. 

Access Controls Cont.

This week I continued reading over access controls in the intro to CISSP book. The two categories of access controls are:

·         System access controls: Controls in this category protect the entire system and provide a first line of defense for the data contained on the system.

·         Data access controls: Controls in this category are specifically implemented to protect the data contained on the system.

System access controls

Although system access controls can provide complete authentication, authorization, and accountability, they’re renowned for authentication. You can base authentication on any of three factors: Something you know, something you have, something you are.

Something you know is normally a password or secret PIN that is used to access a system. Usernames and passwords are the simplest and cheapest way to secure a system but is not the most secure.

Something you have can be a smart card or a token. This concept is based on the assumption that only the owner of the account has the necessary key to unlock the account.

Something you are such as fingerprint, voice, retina, or iris characteristics. This is the most secure form of authentication because it goes under the assumption that only you have access to your eyeball or hand. Biometric systems are some of the most expensive and complicated to implement which makes them rare to see in implementation.

Two-factor authentication requires two of these three authentication factors for authentication. Three-factor authentication requires all three factors for authentication. A commonly cited example of an access control system that uses two-factor authentication is an automatic teller machine (ATM) card and a PIN.

Identification and Authentication

The identification component is normally a relatively simple mechanism based on a username. Identification requirements include only that it must uniquely identify the user (or system/process) and shouldn’t identify that user’s role or relative importance in the organization. Common or shared accounts, such as root, admin, or system should not be permitted. These accounts provide no accountability and are prime targets for Hackers. Passwords are easily the most common and weakest authentication mechanism in use today. Although there are more advanced and secure authentication technologies available, including tokens and biometrics, organizations typically use those technologies as supplements to or in combination with rather than as replacements for traditional usernames and passwords.

A passphrase is a variation on a password; it uses a sequence of characters or words, rather than a single password. Generally, attackers have more difficulty breaking passphrases than breaking regular passwords because longer passphrases are generally more difficult to break than complex passwords. Passphrases also have the following advantages:

·         Users frequently use the same passwords to access numerous accounts; their corporate networks, their home PCs, their e-mail accounts. An attacker who targets a specific user may be able to gain access to his or her work account by going after a less secure system, such as his or her home PC, or by compromising an Internet. Internet sites and home PCs typically don’t use passphrases, so you improve the chances that your users have to use different passwords/passphrases to access their work accounts.

·         Users can actually remember and type passphrases more easily than they can remember and type a much shorter, cryptic password that is more difficult to type.

Passphrases also have a downside:

·         Users can find passphrases inconvenient, so you may find passphrases difficult to implement.

·         Many command-line interfaces and tools don’t support the space character that separates words in a passphrase.

·         A passphrase is still just a password and shares some of the same problems associated with passwords.

The first exercise in Gruyere in on cross site scripting or XXS. Cross-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or Javascript) into contents of a website not under the attacker's control. When a victim views such a page, the injected code executes in the victim's browser. Thus, the attacker has bypassed the browser's same origin policy and can steal victim's private information associated with the website in question.

In a reflected XSS attack, the attack is in the request itself (frequently the URL) and the vulnerability occurs when the server inserts the attack in the response verbatim or incorrectly escaped or sanitized. The victim triggers the attack by browsing to a malicious URL created by the attacker. In a stored XSS attack, the attacker stores the attack in the application (e.g., in a snippet) and the victim triggers the attack by browsing to a page on the server that renders the attack, by not properly escaping or sanitizing the stored data.  There are many venerable parts of the site, but the first feature that is exploited is the file upload. If a HTML file is uploaded with <script>alert(document.cookie);</script> as the content the script is executed and the users cookie information is displayed.

The next vulnerability that can be exploited is the URL. The site is designed to display an error if an invalid destination is entered. For example if you added ‘hello’ to the end of the url

http://google-gruyere.appspot.com/698806340929/hello

This page would be displayed.

Seeing that what you put into the url is being directly injected into the site is a good sign that there is a XXS vulnerability. So imputing the url

http://google-gruyere.appspot.com/698806340929/<script>alert(1)</script>

will run the malicious javascript.

As I continue through gruyere I will be leveraging the source code to find more vulnerabilities.