After Some Analysis on Cross Doamain; We thought to have a White Paper on it. Hope this requires some editing further.
*Brief of CrossDomain Policy* An solution for Information Assurance, which provides access or transfer of information between two or more secure domains. *Same-Origin Policy* Content from one website should not be able to read or alter the content from another website. This must follow the fundamental building block of browser security. Sending information across-domains has always been allowed Ex. for Same Origin http://www.examplesite.org/here http://www.examplesite.org/there same protocol: http, host: examplesite, default port 80 Ex. for Different Origin Policy: http://www.examplesite.org/here https://www.examplesite.org/there http://www.examplesite.org:8080/thar http://www.hackerhome.org/yonder Different protocol: http vs. https, different ports: 80 vs. 8080, different hosts: examplesite vs. hackerhome Reference: http://en.wikipedia.org/wiki/Same_origin_policy *Implemented examples for Cross-Domain Policy* Introduced in IE 8 (Existing) Security based on Microsoft’s Internet Zones Protocols must match (file:// <-> file://) Cookies: Does not send cookies HTTP Methods: Only allows GET or POST Refinement: Per URI Revised in Beta 2 to support W3 Access-Control Access-Control-Allow-Origin header * * *Sample Code for the above ** if (window.XDomainRequest) { xdr = new XDomainRequest(); if (xdr) { //Assign handlers to xdr {not shown} xdr.open(“POST", “http://www.example.org/xdr.cgi”); xdr.send(“HTTP_VAR=hello%20World”); } function readdata() { var dRes = document.getElementById('dResponse'); dRes.innerText = xdr.responseText; alert("Content-type: " + xdr.contentType); alert("Length: " + xdr.responseText.length); }* Reference: http://www.w3.org/TR/access-control/#origin0 Authorizes cross-domain XML HTTP Requests (XHR) Recently adopted by Microsoft and Mozilla Still in development Sends cross-domain authorization information in headers Responses are per-full URI Reference: http://www.w3.org/TR/access-control/#access-control-request-headers *************** Adobe CSD Implementation Example Developed by Adobe in 2005 Allows reading of HTTP response body Does not grant access to header data Governs GET requests and file uploads Authentication sent: Yes HTTPS to HTTPS communication is allowed. HTTP to HTTPS communication not allowed by default. A different policy mechanism exists for sockets Per-directory permissions *What Developers should Follow? * Developers need supported methods for cross-domain communication without the risk of cross-site request forgery Cross-domain may not carry risk if the two domains are both controlled by the same development group or there is an approved API. www.example.org & data.example.org Generally, information on the web is put explicitly so as to make current information available for as many people as possible. Like: 1. Daily Stock Information 2. Election Results 3. Finance Statistics 4. Weather information ** *There exists 3 type of Controls:* Domains with whom you want to share data Custom headers you are willing to receive from web sites Whether other cross-domain policy files exist on the server Example of Cross Domain File *<cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain=“example.com“ secure=“true”/> <allow-access-from domain=“*.example.com“ secure=“true”/> <allow-http-request-headers-from domain="**www.example.com*<http://www.example.com/> *" headers="SOAPAction" secure=“true"/> </cross-domain-policy>* *Occuring Threats* 1. Header Access 2. Cross-Site Scripting 3. Cross Site Reference Forgery 4. Sensitive Information Leakage *Header Access* All models attempt to limit access to HTTP headers This could be subverted if the server has risky practices such as: Allowing the TRACE HTTP method Echoing SessionIDs in the body of the response as part of URLs *XSS * Cross-Site Scripting filters may not be prepared for the new JavaScript. Like with JSON, developers will have to be careful how they handle the data from cross-document messaging. Traditional cross-site scripting attacks will continue to exist. *CSRF* Cross-site request forgery attacks may have access to the response data. Overly permissive cross-domain implementations could allow this attack. The ORIGIN header may assist in reducing this attack. *Sensitive Information Leakage* Attackers have access to the body of the response which may contain sensitive information. This can occur when the principle of least privilege is not followed: Wildcards are provided in the domain of the root cross-domain policy The cross-domain policy is not limited to a specific sub-directory or file Some models do send cookies to ensure the server has all the information necessary to decide privilege. Some models don’t send cookies because they don’t want to risk a mistake by the server. *Best Practices* Does the control limit based on protocols? Does the control limit based on ports? Does the control limit based on the full URI? Does the remote domain allow user uploaded content? *Define TRUST Content* It may be tempting for developers to believe that content that processes cross-domain data trusted because they authored it However, even though the code is trusted, it is still parsing untrusted data Developers should consider whether to host the cross-domain code on their trusted domain or leverage same-origin protections by moving the code onto a separate domain *Domains that Allow Cross Domain Requests* Remember that users are trusting you not to share their information Avoid wildcards Utilize path or URI controls when available Don’t allow headers unless you want them Only request authentication via W3C Access Control if necessary Do not all incoming XDM on sensitive pages Utilize safe data handling such as toStaticHTML and JSON parsing on XDM requests *Domain That Request Data from Other Domains:* User’s are trusting you not to send their information in the request The remote site is trusting you with their information Someone may be spoofing the receiving domain on the network Do not allow XDM on pages containing sensitive data Perform data validation *Avoid Cross-Domain Permissions:* Mixed HTTP/HTTPS cross-domain communication Relaying through a proxy is more appropriate Cross-domain may not be appropriate for sites hosting sensitive information The solution would require wildcard permissions on an internal web server *Conclusion:* Appropriate for sharing between sites owned by common entities Developers need to be educated about the controls they are using Designed cross-domain communication is better than ad-hoc solutions The variety of solutions will provide developers with choices Regards, Srinivas Naik On Wed, Jun 2, 2010 at 8:29 PM, Sandeep Thakur <[email protected]> wrote: > Team, > I understand we Information security professionals scans the application > but may not recommend few already known best in-class steps as remediations > for well-known vulnerabilities. Lets discuss all such terminology starting > with Same Origin and Cross Domain policies. You all can extend with all know > terminologies: > > Visit the below link for detailed information on Same Origin methods.... > http://en.wikipedia.org/wiki/Same_origin_policy > > Visit the below link for detailed information on Cross Domain methods.... > http://msdn.microsoft.com/en-us/library/cc709423(VS.85).aspx > > I believe this will be helpful for all... Thanks! > > > Regards > Sandeep Thakur > > -- > You received this message because you are subscribed to the Google Groups > "nforceit" group. > To post to this group, send an email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nforceit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nforceit?hl=en-GB. > -- You received this message because you are subscribed to the Google Groups "nforceit" group. To post to this group, send an email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nforceit?hl=en-GB.
