Data Validation Testing

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

In Cross Site Scripting (XSS) testing, we test if it is possible to manipulate the input parameters of the application so that it

generates malicious output. We find an XSS vulnerability when the application does not validate our input and creates an

output that is under our control. This vulnerability leads to various attacks, for example, stealing confidential information

(such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input ->

Output == cross-site scripting

when i tried for testing XXS vulnerability for url akakom .ac.id/index.php?login=<script>alert(coba</script> i was found an attempt  like below :

this attempt not allow for input script tag.

TESTING FOR STORED CROSS SITE SCRIPTING (OWASP-DV-002)

Stored Cross Site Scripting (XSS) is the most dangerous type of Cross Site Scripting. Web applications that allow users to

store data are potentially exposed to this type of attack. This chapter illustrates examples of stored cross site scripting

injection and related exploitation scenarios.

I try for use BeEF

when i click apply config i was on the akakom.ac.id page.

TESTING FOR DOM BASED CROSS SITE SCRIPTING (OWASP-DV-003)

DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically

JavaScript, obtaining user input and then doing something unsafe with it to lead to an XSS bug. This document will only

discuss JavaScript bugs which lead to XSS.

The DOM, or Document Object Model is the structural format that may be used to represent documents in the browser.

The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a

session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains

obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content,

such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by

an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and

formalized testing exists.

i cant do this phase because this web application not allow for input script in url.

TESTING FOR CROSS SITE FLASHING (OWASP-DV-004)

ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs.

ActionScript, like every other language, has some implementation patterns which could lead to security issues.

In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting

could be present in flawed Flash applications.

Sorry I can do this phase and i just read for

Understanding Flash Player 9 April 2008 Security Update compatibility

obe released a security update for Flash Player 9 (Flash Player 9,0,124,0) on April 8, 2008, to strengthen the security of Adobe Flash Player for our customers and end users, and to provide further mitigations for previously disclosed vulnerabilities. The Flash Player security update provides further mitigations for issues listed in the December 2007 Security Bulletin APSB07-20 for DNS rebinding and cross-domain policy file vulnerabilities, andSecurity Advisory APSA07-06 for cross-site scripting vulnerabilities in SWFs.

Customers are advised to review the following Flash Player updates to determine if their content will be impacted, and to begin implementing necessary changes immediately to help ensure a seamless transition. This document provides an overview of the upcoming Flash Player changes, links to TechNotes, and relevant documentation to help you better prepare.

If any of the following situations apply, you should read this article in detail:

• You use sockets or XMLSockets, regardless of the domain to which you are connecting
• You use addRequestHeader or URLRequest.requestHeaders in any network API call when sending or loading data cross-domain
  or
  You provide access to content on remote domains as a web service provider
• You have SWFs that are exported for Flash Player 7 (SWF7) or earlier that communicate with the hosting HTML by any means
• You use "javascript:" through network APIs to communicate outside a SWF

Adobe also recommends that customers subscribe to the Security Notification Service to receive e-mail notification for the final security bulletin and advisory releases.

A socket policy file will always be required for all socket connections

This security update will make the optional socket policy file changes introduced in Flash Player 9,0,115,0 mandatory. A socket policy file is a policy file deployed by a socket. The default socket meta-policy is "all", so socket policy files can be loaded from the socket master policy port (843) or from a custom port.

Note that with this change in Flash Player, HTTP policy files will no longer permit socket access. Flash Player has two types of policy files: HTTP policy files that are crossdomain.xml files on a server and define whether SWFs from other domains can load that server's content; and socket policy files, which define what ports Flash Player can connect to via socket or XMLSocket connections. In the latest Flash Player, the rules regarding socket policy files have changed.

These changes support the goal of DNS hardening, which helps to ensure that ActionScript cannot be used as a means for a DNS rebinding attack (as referenced in Security Bulletin APSB07-20) that could result in an unauthorized socket connection. In the previous update (Flash Player 9,0,115,0), implementing socket policy files was optional; violations of the strict policy file rules result only in warnings in Debug versions of Flash Player. In this update of Flash Player, these warnings are now errors and SWF files that depend on the older socket policy rules may stop functioning as intended.

Flash Player 9,0,115,0 introduced the following concepts:

• Socket master policy files, which are served from the fixed TCP port number 843 (this provides a standard port to serve a socket policy file from a host)
• Socket meta-policies, a "policy on policies" that allows a server administrator to designate what socket policy files are permitted to exist on a server
• Strict socket rules, which require a socket policy file for socket connections

What is impacted?

Any content using sockets or XMLSockets, including configurations in which the following is true:

• A SWF is currently relying on a crossdomain.xml file in the root directory of a web server to authorize socket connections back to the same host on ports greater than 1024
• A SWF attempts a socket or XMLSocket connection back to its own host without performing aloadPolicyFile call to retrieve a socket policy file
• A SWF attempts a socket or XMLSocket connection back to its own host and loads a policy file that does not list its own domain within the allowed domains

What do I need to do?

Impacted customers should first review the socket policy files section of the Flash Player Developer Center article,Policy file changes in Flash Player 9, in order to learn the new rules and changes. For details on how to determine if your site is affected by this change, see the following TechNote (kb403364): Sockets no longer functional in Flash Player versions greater than 9,0,115,0.

To update your content, you need to create a socket policy file to permit connections to the host socket. The policy file can be served from either the socket master policy port 843 or from the destination port of the socket connection. The socket policy file will need to include all domains that are allowed to connect to the socket, including itself. If the socket policy file is hosted from the master policy file location, be sure to include meta-policies where socket policy files are allowed to be located. You may need to check that your content performs aloadPolicyFile call to ensure that Flash Player is aware of where to load the policy file from. Use the instructions for configuring policy file logging in Tech Note kb403364 to verify your changes.

A policy file will be required to send headers across domains

At this time, Flash Player allows SWFs to set arbitrary HTTP request headers on GET and POST requests, with the exception of the blacklist of prohibited headers. The April 2008 Flash Player update adds a new security feature to perform a cross-domain policy file check before allowing SWFs to send headers to another domain. This change helps improve web site security by helping to defend against malicious HTTP headers sent by content from other domains. The feature will also help to mitigate a potential UPnP issue (VU#347812) in which routers fail to correctly handle unexpected header values.

In order for a SWF to send a header anywhere other than its own host, the origin domain of the SWF must have explicit permission from the host to which the header is being sent, in the form of a policy file. The existing policy file model will apply, with the same file locations and ActionScript APIs, but a new syntax will be required. To specify header-sending rights, use this new tag: <allow-http-request-headers-from>.

Flash Player will continue to allow any header not on the blacklist to be sent to the host of the SWF, and additional headers will be added to the blacklist as needed. As a result of this new security feature, the HTTP Authorization header, which was added to the blacklist in Flash Player 9,0,115,0, will be removed from the blacklist but will follow the new cross-domain policy file rules.

What and who is impacted?

The following are impacted:

• Any application that is sending custom HTTP headers to a different domain or host than the sending SWF's origin, using the ActionScript 2.0 XML.addRequestHeader or LoadVars.addRequestHeader methods, or the ActionScript 3.0 URLRequest.requestHeaders property
• Web service providers that wish to make their services available to Flash based applications hosted on another domain
• Applications that were impacted by the restriction on HTTP Authorization headers in Flash Player 9,0,115,0

What do I need to do?

Impacted customers should arrange for a policy file to be added or updated to include the new header policy tags on the site to which the headers are being sent. Additionally, if the crossdomain.xml policy file is in a non-default location—a directory other than the server's document root—customers may need to add an ActionScript call toloadPolicyFile and republish the affected SWFs.

As a reminder, Adobe strongly encourages customers to implement meta-policy tags within crossdomain.xml in preparation for future changes to cross-domain policy file behavior. The meta-policy file is optional in Flash Player 9,0,115,0 and will throw a security warning but is expected to become mandatory and throw a security error in a future release.

For more details on the new cross-domain policy file tag and syntax, and affected APIs, see the following TechNote (kb403185): Arbitrary headers fail to be sent from the Flash Player to a remote domain.

The allowScriptAccess default will always be "sameDomain"

The allowScriptAccess default, which is used when the parameter is not specified, will be updated from "always" to "sameDomain" for all SWFs version 7 and earlier. This changes the behavior of older SWFs to match the current security model and provide greater security by default. The allowScriptAccess permission mechanism is an HTML property of the <object> and <embed> tags that controls the ability of a SWF to call JavaScript code in the surrounding HTML file. The "always" default setting for older SWFs may expose sites to potential cross-site scripting attacks, such as the ones described in Adobe Security Advisory APSA07-06.

What may be impacted?

The change in default behavior may impact content that uses fscommand() and/orgetURL("javascript:...") if all of the following are true:

• The SWF file was published for SWF version 7 or earlier.
• The HTML that sources the SWF file does not specify a value for the allowScriptAccess parameter in the<object>/<embed> tags.
• The HTML and SWF files are served from different domains, or from different hostnames within the same domain. For example, an HTML page on www.mysite.com sources a SWF file from www.anothersite.com or fromcontent.mysite.com.
• The ActionScript code in the SWF file calls JavaScript code in the HTML file, using either fscommand() orgetURL("javascript:...").

Other cases that may be impacted include:

• SWF version 8 (or later) parent SWF loading a remote SWF version 7 and earlier child
• Hosting a SWF without surrounding HTML

What do I need to do?

If this change impacts your content, you can explicitly specify allowScriptAccess="always" in the HTML page where the problem occurs. For websites that host a SWF without surrounding HTML, you will need to add the appropriate surrounding HTML to set Flash Player to run in a less privileged mode.

Be aware that doing this grants permission for the sourced SWF file, and any SWF file that it loads, to execute JavaScript code in the context of your HTML file. If you control the SWF that is sourced, it is appropriate to grant this permission, but if you do not control that SWF, or any SWF that it may load, then you may want to consider carefully whether allowScriptAccess="always" exposes your HTML page to abuse.

"javascript:" URLs will be prohibited in networking APIs, except getURL(), navigateToURL(), and HTML-enabled text fields

To help prevent script execution actions in SWFs that were not intended by the content author, APIs that are not specifically designed for browser interaction will no longer allow "javascript:" URLs. However, getURL() andnavigateToURL() will continue to accept them.

These "javascript:" URLs were not intended to be permitted within all networking APIs, and this new behavior helps provide greater security for customers and end users. As an example of a potential vulnerability of this type, consider a SWF that is designed to call Loader.load(), which can be passed a URL supplied in a query string parameter. The developer may expect only "http:" calls but may be passed "javascript:" from an attacker. Validating input is a best practice for helping to protect your site from a potential attack; however, it is a step that many developers fail to take.

This change to the networking APIs further helps mitigate cross-site scripting injections that may result from improper input validation, such as the ones described in Adobe Security Advisory APSA07-06.

What may be impacted?

Content that uses "javascript:" URLs within networking APIs. Note that "vbscript:" is treated the same as "javascript:" in this context.

What should I do?

If your content is using "javascript:" within the prohibited networking APIs, you will need to rewrite your content. Developers are encouraged to use the ExternalInterface class for JavaScript-to-ActionScript communication.

Where to go from here

Review Creating more secure SWF web applications in the Flash Player Developer Center for more tips on how to develop more secure code. Also, learn how the Flash Player 9 security architecture and new APIs help you deliver trusted content to your users in the Flash Player 9 security white paper.