That seems reasonable to me, besides not being able to do it by hand with loadPolicyFile(). If you've already got a web server, and you're trying to connect from flash to something on port > 1024, you should be able to tell it to get the policy file from another port or from the web server. As long as it's coming from the same IP address, what reason is there to not allow this? I can see plenty of situations where you've got a socket listening on a high port number, and you have access to web space on that server, but no root access to bind to port 843 :(
Also, can somebody explain the DNS rebind thing to me? If I'm abusing my own DNS server for nefarious purposes, why do I need the Flash player as an attack vector? You can't bind to a different class c without a root server can you? -Josh On Fri, Jun 13, 2008 at 2:06 PM, e_baggg <[EMAIL PROTECTED]> wrote: > I finally got it working. No matter what, the Flash player makes a > request to port 843 asking for the cross-domain...even if you call > Security.loadPolicyFile(). I found a source example where a Java > socket (which I kicked off in a shell script) listens on port 843 and > returns the policy file. So, I therefore never need to call > Security.loadPolicy(). Here's the link to that library. You need to > make sure this port is open on your firewall which is easily testable > with a telnet call. This port 843 method is actually the recommended > way to do it according to Adobe. > > http://www.flash-resources.net/ > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, "Josh > McDonald" <[EMAIL PROTECTED]> wrote: > > > > Let us know how it works. It's really a painful process really, > there's got > > to be a better way to secure the player against attacks without > requiring > > funky custom sockets needing being opened :( > > > > -Josh > > > > On Fri, Jun 13, 2008 at 3:08 AM, e_baggg <[EMAIL PROTECTED]> wrote: > > > > > After thoroughly reading the Adobe socket policy docs, it looks like > > > I'm going to have to open up port 843 and serve the new > > > crossdomain.xml that way. Even though I have it on my root and call > > > Security.loadPolicy() on it (and I see in the logger that it accepts > > > it), it still calls 843, hangs, (b/c it doesn't exist there), than the > > > Flash player throws a security error. Rather frustrating. So it goes. > > > I'm on the debug FP version: WIN 9,0,124,0 > > > > > > This crossdomain below is on my root webserver and my app is on port > > > 9080. Even if I move my html and swf to the main root (port 80)..it > > > still fails. > > > > > > <?xml version="1.0"?> > > > <!DOCTYPE cross-domain-policy SYSTEM > > > "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd";> > > > <cross-domain-policy> > > > <site-control permitted-cross-domain-policies="master-only"/> > > > <allow-access-from domain="*" to-ports="8080-9080"/> > > > </cross-domain-policy> > > > > > > > > > --- In flexcoders@yahoogroups.com > > > <flexcoders%40yahoogroups.com><flexcoders% > 40yahoogroups.com>, > "Josh > > > McDonald" <dznuts@> wrote: > > > > > > > > You can set any headers you like so long as they're specified in > your > > > > crossdomain.xml, and they're not on the "banned" list. > > > > > > > > Details: > > > > > > > > > > > > > > > > http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html#policy_file > > > > > > > > Baninanted headers: > > > > > > > > > > > > > > > > http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403030&sliceId=1 > > > > > > > > AFAIK jsessionid is a cookie and the browser should be putting it in > > > to any > > > > request made from Flex via HttpService. You may have the one Flash > > > Player > > > > version (apparently 9.0.115.0) that blocks Authorization header > info. > > > > > > > > -Josh > > > > > > > > On Thu, Jun 12, 2008 at 2:20 PM, e_baggg <e_baggg@> wrote: > > > > > > > > > I am doing hand-rolled GETs because Flex (HttpService) cannot pass > > > > > headers (ie jessionid). Thus, I need to open my own > flash.net.Socket > > > > > and write/read the request/response manually. It works great with > > > > > Digest authorization except for this policy issue. I suppose I > can get > > > > > around this making the login page a JSP and make the redirect > go to > > > > > the swf html page...and from there use HttpService....but > still I hate > > > > > hacks. Such a shame this policy stuff is such a nightmare. I > followed > > > > > the Adobe docs exactly and I still have issues. I'll work on > this more > > > > > and report back anything I find. > > > > > > > > > > > > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com> > <flexcoders%40yahoogroups.com><flexcoders% > > > > 40yahoogroups.com>, > > > > > > "Josh > > > > > McDonald" <dznuts@> wrote: > > > > > > > > > > > > Also, maybe we should look at the root of the problem - what > is it > > > > > you're > > > > > > actually trying to do via sockets and hand-rolled GETs that you > > > can't do > > > > > > with httpService? > > > > > > -Josh > > > > > > > > > > > > On Thu, Jun 12, 2008 at 9:51 AM, Josh McDonald <josh@> wrote: > > > > > > > > > > > > > You'll have to use something like Charles to listen to > what Flash > > > > > player is > > > > > > > doing behind your back for the policy file to be sure, but > if you > > > > > try and > > > > > > > open a socket to somedomain.com:9080, I believe Flash is > going to > > > > > look for > > > > > > > somedomain.com:80/crossdomain.xml - Flash doesn't know that > > > the socket > > > > > > > you're connecting to is a http server, so it only knows to > > > look in the > > > > > > > default location, and it's not going to get your > crossdomain file > > > > > if it's on > > > > > > > the server listening on 9080. > > > > > > > Like I said, check with Charles to be sure, but it would make > > > > > sense to me > > > > > > > at least. > > > > > > > > > > > > > > -Josh > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 12, 2008 at 8:35 AM, e_baggg <e_baggg@> wrote: > > > > > > > > > > > > > >> I spoke too soon. The 3 second delay still exists and when I > > > set up > > > > > > >> the Swf policy file debugger for Windows...the Flash player > > > outputs > > > > > > >> this. My concern is that first warning. According to the > docs, > > > > > calling > > > > > > >> Security.loadPolicyFile() to the domain and port (which line > > > 2 says > > > > > > >> happened ok) should fix everything. I just updated my > Windows XP, > > > > > > >> which I read somewhere upgrades the flash player. I still > > > have the > > > > > > >> debug version though. This is all a mess to me. > > > > > > >> > > > > > > >> OK: Root-level SWF loaded: > > > http://my.domain.com:9080/xms-app/xms.swf > > > > > > >> OK: Policy file accepted: > > > http://my.domain.com:9080/crossdomain.xml > > > > > > >> Warning: Timeout on xmlsocket://my.domain.com:843 (at 3 > seconds) > > > > > while > > > > > > >> waiting for socket policy file. This should not cause any > > > problems, > > > > > > >> but see http://www.adobe.com/go/strict_policy_files for an > > > > > explanation. > > > > > > >> Warning: [strict] Requesting socket policy file from > > > > > > >> xmlsocket://my.domain.com:9080 due to socket connection > > > request from > > > > > > >> SWF at http://my.domain.com:9080/xms-app/xms.swf. See > > > > > > >> http://www.adobe.com/go/strict_policy_files if this causes > > > problems. > > > > > > >> Warning: Timeout on xmlsocket://my.domain.com:9080 (at 3 > seconds) > > > > > > >> while waiting for socket policy file. This should not > cause any > > > > > > >> problems, but see http://www.adobe.com/go/strict_policy_files > > > for an > > > > > > >> explanation. > > > > > > >> Warning: SWF from http://my.domain.com:9080/xms-app/xms.swf > > > will be > > > > > > >> permitted to connect to a socket in its own domain without a > > > policy > > > > > > >> file. This configuration is deprecated. See > > > > > > >> http://www.adobe.com/go/strict_policy_files to fix this > problem. > > > > > > >> Warning: SWF from http://my.domain.com:9080/xms-app/xms.swf > > > will be > > > > > > >> permitted to connect to a socket in its own domain without a > > > policy > > > > > > >> file. This configuration is deprecated. See > > > > > > >> http://www.adobe.com/go/strict_policy_files to fix this > problem. > > > > > > >> > > > > > > >> --- In flexcoders@yahoogroups.com<flexcoders%40yahoogroups.com> > <flexcoders%40yahoogroups.com> > > > <flexcoders%40yahoogroups.com><flexcoders% > > > > > 40yahoogroups.com>, > > > > > > >> "e_baggg" <e_baggg@> wrote: > > > > > > >> > > > > > > > >> > Actually, I stand corrected. Once I added in my port # > to the > > > > > > >> > cross-domain...it worked. Thanks again gang! Big help! > > > > > > >> > > > > > > > >> > > > > > > > >> > <cross-domain-policy> > > > > > > >> > <allow-access-from domain="*" to-ports="9080,8080"/> > > > > > > >> > </cross-domain-policy> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > --- In > flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><flexcoders% > 40yahoogroups.com> > > > <flexcoders%40yahoogroups.com><flexcoders% > > > > > 40yahoogroups.com>, > > > > > > >> "e_baggg" <e_baggg@> wrote: > > > > > > >> > > > > > > > > >> > > Thanks for your response...I have a full access cross > domain > > > > > on my > > > > > > >> > > server and loading it via Security.loadPolicyFile() does > > > > > nothing as > > > > > > >> > > well. Hmm... > > > > > > >> > > > > > > > > >> > > <cross-domain-policy> > > > > > > >> > > <allow-access-from domain="*"/> > > > > > > >> > > </cross-domain-policy> > > > > > > >> > > > > > > > > >> > > --- In > flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com><flexcoders% > 40yahoogroups.com> > > > <flexcoders%40yahoogroups.com><flexcoders% > > > > > > > > 40yahoogroups.com>, > > > > > > > > > > > >> å`¨æŒ¯å(R)‡ <zhenyu.zhou@> wrote: > > > > > > >> > > > > > > > > > >> > > > When you use a socket or xmlsocket in a remote swf > file, > > > > > > >> > > > flashplayer would send a policy-request to the server. > > > > > > >> > > > Check > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_04.html > > > > > > >> > > > > > > > > > >> > > > When you run it locally, flashplayer won't do this. > > > > > > >> > > > > > > > > > >> > > > I'm not sure if this is the reason. > > > > > > >> > > > Maybe you should call Security.loadPolicyFile() > yourself > > > > > and let > > > > > > >> the > > > > > > >> > > > server give it a correct respond. > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > Josh McDonald wrote: > > > > > > >> > > > > > > > > > > >> > > > > It sounds to me like your server is simply > holding the > > > > > > >> > connection for > > > > > > >> > > > > a few seconds in order to prevent brute-force > password > > > > > attacks. > > > > > > >> > > > > > > > > > > >> > > > > -Josh > > > > > > >> > > > > > > > > > > >> > > > > On Wed, Jun 11, 2008 at 6:23 AM, e_baggg <e_baggg@ > > > > > > >> > > > > <mailto:e_baggg@>> wrote: > > > > > > >> > > > > > > > > > > >> > > > > This is baffling me. For authentication reasons, I am > > > doing > > > > > > >> > all my > > > > > > >> > > > > HTTP traffic via a custom flash.net.Socket where I > > > create and > > > > > > >> > > parse > > > > > > >> > > > > the HTTP request/response myself (using Digest > > > > > authorization). > > > > > > >> > > > > Everything works fine when I run the generated > > > html/swf files > > > > > > >> > > locally, > > > > > > >> > > > > but once I deploy them to the unprotected part of a > > > > > > >> > webserver, the > > > > > > >> > > > > response connection is not dropped by the server for > > > several > > > > > > >> > > seconds. > > > > > > >> > > > > I do a GET and receive the 401 immediately...send the > > > > > same GET > > > > > > >> > > request > > > > > > >> > > > > again with the Digest info. I receive the correct > > > response > > > > > > >> > > from the > > > > > > >> > > > > server immediately but the socket is not closed for 4 > > > seconds > > > > > > >> > > by the > > > > > > >> > > > > server. Has anyone seen this? > > > > > > >> > > > > > > > > > > >> > > > > I have "Connection: close" in my request but the > > > socket is > > > > > > >> > > still kept > > > > > > >> > > > > open. If I access this URI via browser URL bar, > the delay > > > > > > >> is not > > > > > > >> > > > > there. I sniffed the packets and even if I mimic the > > > request > > > > > > >> > > String > > > > > > >> > > > > exactly, the socket still hangs for 4 seconds. I > > > suspect I > > > > > > >> > am not > > > > > > >> > > > > closing the socket request, though '\r\n\r\n' seems > > > to be the > > > > > > >> > > standard > > > > > > >> > > > > (and it works when it runs locally). Any ideas??? > > > > > > >> > > > > > > > > > > >> > > > > Here is my exact request that hangs though the 200 > > > > > response is > > > > > > >> > > > > received immediately: > > > > > > >> > > > > > > > > > > >> > > > > GET /myapp/mydata.xml HTTP/1.1\r\n > > > > > > >> > > > > Host: www.mydomain.com <http://www.mydomain.com>\r\n > > > > > > >> > > > > Content-Type: application/x-www-form-urlencoded\r\n > > > > > > >> > > > > Keep-Alive: 1\r\n > > > > > > >> > > > > Connection: close\r\n > > > > > > >> > > > > Cookie: > JSESSIONID=8CCB32BBEDB875F082709FE17AA93679;\r\n > > > > > > >> > > > > Authorization: Digest username="user1", > realm="MYAPP", > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > nonce="MTIxMzEyODYwOTE0MDo1Njg5NTllYTUxMDYyN2VmNGNmMjViMTA4MDFiMDRjMA==", > > > > > > >> > > > > uri="/myapp/mydata.xml", > > > > > > >> > > response="1175bbe7d5840a0d94fb5de3ef16a2a3", > > > > > > >> > > > > qop=auth, nc=1, cnonce="0a4f113b"\r\n\r\n > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > -- > > > > > > >> > > > > "Therefore, send not to know For whom the bell > tolls. It > > > > > tolls for > > > > > > >> > > thee." > > > > > > >> > > > > > > > > > > >> > > > > :: Josh 'G-Funk' McDonald > > > > > > >> > > > > :: 0437 221 380 :: josh@ <mailto:josh@> > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > "Therefore, send not to know For whom the bell tolls. It > tolls for > > > > > thee." > > > > > > > > > > > > > > :: Josh 'G-Funk' McDonald > > > > > > > :: 0437 221 380 :: josh@ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > "Therefore, send not to know For whom the bell tolls. It > tolls for > > > > > thee." > > > > > > > > > > > > :: Josh 'G-Funk' McDonald > > > > > > :: 0437 221 380 :: josh@ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > "Therefore, send not to know For whom the bell tolls. It tolls for > > > thee." > > > > > > > > :: Josh 'G-Funk' McDonald > > > > :: 0437 221 380 :: josh@ > > > > > > > > > > > > > > > > > > > > > -- > > "Therefore, send not to know For whom the bell tolls. It tolls for > thee." > > > > :: Josh 'G-Funk' McDonald > > :: 0437 221 380 :: [EMAIL PROTECTED] > > > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
