can any one Explain "what is Cross-Frame Scripting and Security?"

Cross Frame Scripting (XFS) is an attack that belongs to the Cross Site Scripting family. The attacker using this technique injects code in a frame.

With Dynamic HTML (DHTML), content in different windows and frames can interact in powerful ways by scripting with the object model.
However, since a browser can simultaneously display unrelated documents in its various windows and frames, certain rules must be enforced to protect data integrity and privacy of information.

__________________
With,
J. Jeyaseelan
Everything Possible

Cross-site-scripting

Cross-Site Scripting attacks are an instantiation of injection problems, in which malicious scripts are injected into the otherwise benign and trusted web sites.

__________________
With,
J. Jeyaseelan
Everything Possible

Cross-Site Scripting (XSS) vulnerabilities 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.

__________________
With,
J. Jeyaseelan
Everything Possible

to know more on Cross site scripting click below
Cross-site-scripting - OWASP

__________________
With,
J. Jeyaseelan
Everything Possible

to know more on Cross Frame Scripting click the below link
Cross Frame Scripting - OWASP

__________________
With,
J. Jeyaseelan
Everything Possible

Cross-site scripting (XSS)

A cross-site scripting (XSS) hole is when an attacker can inject scripts into a page sent by your server. Browsers treat these injected scripts like any other script in the page.A cross-site scripting (XSS) h

Avoiding XSS holes

"Open redirect" scripts should not redirect to URLs with special protocols that inherit the security context of the site (hi Gmail). In Firefox, these protocols are javascript: and data:.

For sites where the input is meant to be plain text, the fix is simple: escape everything as it is output as HTML, using an escaping mechanism appropriate to where it is.

* Text in HTML and HTML attributes: escape & < > " ' as &amp; &lt; &gt; &quot; '
* Text in JavaScript strings: escape \ / ' " as \\ \/ \' \". (It is not immediately obvious why you must escape / as \/. The reason is not because of how JavaScript is parsed, but because of how HTML is parsed. HTML parsers in web browsers interpret any </script> as the close of a <script> tag.)

Your choice of server-side libraries may affect how easy it is to get this right. If your HTML generation is based on concatenating strings and calling functions to escape variables that might contain certain characters, security depends on "remembering to escape" every variable. One alternative is to use an API where you're constructing a DOM tree out of elements and text nodes. Another is to use an API where you're opening tags, giving them attributes, closing tags, and outputting text. If implemented well, these abstractions might make server-side programming easier and improve a site's speed in addition to making the code less error-prone.

To be safe from XSS, sites should also specify the character set of every page. Browsers use all kinds of crazy heuristics to determine the character set when it is not specified, and the inputs to the heuristics are more or less control of an attacker. For example, browsers may take the character set of the linking page, byte distributions within the page, and the user's language into account. Some character sets (such as UTF-7) have ways of representing the < character without using the byte corresponding to that character in ASCII, which can lead to XSS if a browser thinks your site is UTF-7.

Avoiding XSS holes in sites that allow HTML

For sites where users are allowed to use HTML, the goal is not to escape the input, but to restrict what HTML features can be used.

The level of restriction depends on the site. A site like MySpace may decide to let users customize the appearance of their pages as much as they want. In contrast, a forum will probably limit users to P, BLOCKQUOTE, lists, simple inline styles, and perhaps images.

The naive approach of "stripping tags" using regular expressions often misses things because it interprets them differently than browsers do. For example, the regular expression <.*?> matches nothing in "<script src='http://evil.com/evil.js' </script", leaving your Internet Explorer and Firefox visitors vulnerable (see bug 226495 and for details about "half-tag" parsing). Gerv has an example involving unterminated entities. RSnake maintains an extensive list of XSS vectors that naive filtering may miss.

TODO: go through RSnake's list and make sure my advice covers everything.

The best approach is to parse the input HTML on the server, keeping only tags, attributes, and attribute values you want to allow. Upon serialization, the result will be "well-formed" HTML that browsers will parse the same way your server did.

Things you should ensure are never allowed in user-submitted HTML, to protect the accounts of visitors who use Firefox and IE:

* javascript:, vbscript:, and data: URLs in links, images, anywhere.
* <script> tags, with or without src attributes.
* Event attributes (on*), which contain scripts.
* -moz-binding: or behavior: CSS properties inside <style> elements or style attributes.
* HTML is that is not "well-formed" -- you can't be sure how quirky browsers will parse it. (Example: <b <i>Foo)

The above list might not be complete and it is safer to use whitelists than blacklists. For example, only allow http:, https:, and ftp: links rather than allowing all links other than javascript:, vbscript:, and data:.

If you must allow unsanitized, untrusted HTML to be part of your site, ensure that those pages are not on the same hostname as where other users log in. (webmail, web hosts, attachments in a bug-tracking system, Google cache) (see Gerv's proposal)

TODO: test various browsers' interpretation of setting "document.domain" to figure out exactly what "not on the same hostname" needs to mean

Content other than HTML and XSS

If you serve untrusted content as text/plain, be aware that some browsers will ignore the mime type (violating the HTTP spec) and treat it as something other than text/plain. Internet Explorer notoriously treats text/plain content as HTML if it contains anything that looks like a tag, and even Firefox does some sniffing if some of the bytes would be "control characters" in ASCII. The best solution is to treat untrusted text/plain in the same way as untrusted text/html that cannot be modified: serve it from a different hostname.

TODO: find out whether this warning should also apply to application/octet-stream or other mime types.

TODO: find out what the possible results of Firefox's sniffing are. Can it result in treating the content as text/html, or only as something to be downloaded?

Password fields in user-submitted HTML

Web sites should not allow users to put up forms with <input type="password">. Password managers may fill in the password, thinking the form is a legitimate part of the site.

You can probably check the "type" attribute for "input" elements against your whitelist at the same time you filter for XSS.

The exact likelihood that such an attack will succeed depends on the browser used. Firefox and Safari fill in passwords automatically. IE fills in passwords if the user types his username (imagine a form that says "Type your username to find out your Star Wars name!") or double-clicks the username field and then clicks right below it. Opera fills in passwords if the user clicks the wand icon on the toolbar. Even with Opera, users probably aren't as careful with activating the password manager as they would be when actually typing their password, since password manager does defend against ordinary phishing.

This attack was first used in November 2006 against MySpace, which has since fixed their site. Firefox and Safari developers are trying to determine whether they can mitigate the problem for sites that remain vulnerable, hopefully without crippling password management features and thus making users more vulnerable to actual phishing.

Cross-site request forgery (CSRF)

A Cross-site request forgery hole is when a malicious site can cause a visitor's browser to make a request to your server that causes a change on the server. The server thinks that because the request comes with the user's cookies, the user wanted to submit that form.

Depending on which forms on your site are vulnerable, an attacker might be able to do the following to your victims:

* Log the victim out of your site. (On some sites, "Log out" is a link rather than a button!)
* Change the victim's site preferences on your site. (Example: Google)
* Post a comment on your site using the victim's login.
* Transfer funds to another user's account.

Attacks can also be based on the victim's IP address rather than cookies:

* Post an anonymous comment that is shown as coming from the victim's IP address.
* Modify settings on a device such as a wireless router or cable modem.
* Modify an intranet wiki page.
* Perform a distributed password-guessing attack without a botnet. (This assumes they have a way to tell whether the login succeeded, perhaps by submitting a second form that isn't protected against CSRF.)

CSRF attacks usually involve JavaScript to submit the cross-site form automatically. It is possible for a malicious site to make a user submit a form to another site even without JavaScript, however: form fields can be hidden and buttons can be disguised as links or scrollbars.

Hi Buddies

Cross-site request forgery (CSRF)

Intranet sites

Be aware that the DNS protocol allows bogus.attacker.com to resolve to an attacker's IP one minute and your server's IP the next. The "Princeton attack" takes advantage of this and has the same security impact as XSS. Intranet servers should check the Host header and return "400 Bad Request" if an unrecognized hostname is given, as the HTTP spec suggests but does not require. In addition, intranet firewalls should prevent DNS requests on external hostnames from resolving to internal IP addresses. Similarly, browsers, operating systems, and ISPs should all prevent external hostnames from resolving to 127.0.0.1. (Firefox briefly tried to work around Princeton attacks by caching DNS responses for longer than allowed by the DNS protocol; see bug 149943. It no longer does this; see bug 162871, bug 174590, bug 205726, and 223861.)

Maintainers of intranet sites should not neglect other security considerations, such as XSS, CSRF, and SQL injection. Firewalls do not prevent malicious sites loaded in users' browsers from trying XSS attacks.

Regards
Falcon

Hi Buddies

Cross-site request forgery (CSRF)

Purely server-side holes

Some security holes in web sites don't involve web browsers at all and are therefore out of scope for this page. Examples include directory traversal, buffer overflows, SQL injection, and forgetting to apply form access controls to both the page with the form and the code that handles the form. The Web Application Security Consortium's Threat Classification enumerates common server-side holes.

Regards
Falcon

hi,

can any one Explain What does XSS and CSS mean?

hi,

Often people refer to Cross Site Scripting as CSS. There has been a lot of confusion with
Cascading Style Sheets (CSS) and cross site scripting. Some security people refer to Cross Site
Scripting as XSS. If you hear someone say "I found a XSS hole", they are talking about Cross Site
Scripting for certain.

hi,

What are the threats of Cross Site Scripting?

If any one knows this please explain

hi senraj,

Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application
to fool a user (Read below for further details) in order to gather data from them. Everything from
account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible.
New malicious uses are being found every day for XSS attacks. The post below by Brett Moore brings up a
good point with regard to "Denial Of Service", and potential "auto-attacking" of hosts if a user simply
reads a post on a message board.

__________________
Thanks & Regards,
R.Kamalakannan.

hi,

What are some examples of cross site scripting attacks?

hi senraj,

One product with many XSS holes is the popular PHP program PHPnuke. This product is often
targeted by attackers to probe for XSS holes because of its popularity. I have included a few
links of advisories/reports that have been discovered and disclosed just from this product alone.
The following collection should provide plenty of examples.

Vulnerability Archive -> PHP
Vulnerability Archive -> PHP
Vulnerability Archive -> PHP

__________________
Thanks & Regards,
R.Kamalakannan.