what is hacking cross site scripting ?

what is cross site scripting for hacking?

        Hacking  scripting Descripting

xss vulnerabilities target scripts embedded in a page that are executed on the client side i.e. user browser rather then at the server side.

These flaws can occur when the application takes untrusted data and send it to the web browser without proper validation.

Attackers can use XSS to execute malicious scripts on the users in this case victim browsers.

Since the browser cannot know if the script is trusty or not, the script will be executed, and the attacker can hijack session cookies, deface websites, or redirect the user to an unwanted and malicious websites.

Implication:

1. Making the use of this security vulnerability, an attacker can inject scripts into the application, can steal session cookies, deface websites, and can run malware on the victim's machines.

Vulnerable Objects

·        Input Fields

·        URLs

Examples

1.  script>alert("xss")</script>

The above script when run on a browser, a message box will be displayed if the site is vulnerable to XSS.

The more serious attack can be done if the attacker wants to display or store session cookie.

2.  <iframe> <src =  width = 500 height 500></iframe>

The above script when run, the browser will load an invisible frame pointing to http://google.com.

The attack can be made serious by running a malicious script on the browser.

Recommendations

1.     White Listing input fields

2.     Input Output encoding

Broken Authentication and Session Management

Description

The websites usually create a session cookie and session ID for each valid session, and these cookies contain sensitive data like username, password, etc.

When the session is ended either by logout or browser closed abruptly, these cookies should be invalidated i.e. for each session there should be a new cookie.

If the cookies are not invalidated, the sensitive data will exist in the system.

For example, a user using a public computer (Cyber Cafe), the cookies of the vulnerable site sits on the system and exposed to an attacker.

An attacker uses the same public computer after some time, the sensitive data is compromised.

In the same manner, a user using a public computer, instead of logging off, he closes the browser abruptly.

An attacker uses the same system, when browses the same vulnerable site, the previous session of the victim will be opened.

The attacker can do whatever he wants to do from stealing profile information, credit card information, etc.

A check should be done to find the strength of the authentication and session management.

Keys, session tokens, cookies should be implemented properly without compromising passwords.

Vulnerable Objects

·        Session IDs exposed on URL can lead to session fixation attack.

·        Session IDs same before and after logout and login.

·        Session Timeouts are not implemented correctly.

·        Application is assigning same session ID for each new session.

·        Authenticated parts of the application are protected using SSL and passwords are stored in hashed or encrypted format.

·        The session can be reused by a low privileged user.

Implication

·        Making use of this vulnerability, an attacker can hijack a session, gain unauthorized access to the system which allows disclosure and modification of unauthorized information.

·        The sessions can be high jacked using stolen cookies or sessions using XSS.

Examples

Airline reservation application supports URL rewriting, putting session IDs in the URL:

An authenticated user of the site wants to let his friends know about the sale and sends an email across.

The friends receive the session ID and can be used to do unauthorized modifications or misuse the saved credit card details.

An application is vulnerable to XSS, by which an attacker can access the session ID and can be used to hijack the session.

Applications timeouts are not set properly. The user uses a public computer and closes the browser instead of logging off and walks away.

The attacker uses the same browser some time later, and the session is authenticated.

Recommendations

1. All the authentication and session management requirements should be defined as per OWASP Application Security Verification Standard.

2. Never expose any credentials in URLs or Logs.

Strong efforts should be also made to avoid XSS flaws which can be used to steal session ids.

Share This

Recent