when I look at the crossdomain, I see it onley accept requests from
twitter
<cross-domain-policy>
<allow-access-from domain="*.twitter.com"/>
</cross-domain-policy>
Yes, we changed crossdomain.xml in response to a security threat last night. Unfortunately, do to an insecure interaction between Flash and browsers, allowing cross-domain requests from any domain opens us to assumed login attacks, which a Japanese security researcher had noted publicly in the last 48 hours.
I didn't alert the list because we wanted to observe the behavior of some of our Flash assets after the change, and so the current contents of crossdomain.xml are not yet concrete. If anyone has suggestions for a crossdomain.xml that's both secure and useful to Flash developers, please let the list know.
On Sun, Mar 9, 2008 at 5:52 AM, <k...@neuroproductions.be> wrote:
> I fixed my app, by getting the data via php on my own domain, but the > core problem remains
Yup, and it neutered Twitter Karma, which relied on the permissive crossdomain.xml that twitter.com was publishing. :-)
Oh well, I guess that's the end of using Flash for making Twitter API requests ... for anyone other than Twitter, of course.
-- Dossy
-- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
@ Dossy : you can always reach the api via a server-side script on
your own domain (and put your own "allow all" crossdomain.xml in if
needed)
there is a nice php class in the docs that you can use
@Alex,Twitter: Can't you use an other domain for the API, just like
the yahoo and google APIs ? at least check how they do it. with the
key and stuff.
Anyway, I hope it gets fixed :)
On 2008.03.09, k...@neuroproductions.be <k...@neuroproductions.be> wrote:
> @ Dossy : you can always reach the api via a server-side script on > your own domain (and put your own "allow all" crossdomain.xml in if > needed) there is a nice php class in the docs that you can use
The great thing about Twitter Karma was that users' ID and passwords never touched my server--all communication was directly between the end-user's browser and twitter.com's servers.
I don't use many Twitter "tools" because I don't hand out my own auth. credentials to third parties, so I wanted to make Twitter Karma a tool that I would feel comfortable using if someone _else_ had implemented it.
Proxying requests through my servers will naturally "work" but I wouldn't want to send my auth. credentials through some third-party server, therefore I don't like asking other users to do it.
> @Alex,Twitter: Can't you use an other domain for the API, just like > the yahoo and google APIs ? at least check how they do it. with the > key and stuff. Anyway, I hope it gets fixed :)
Me too.
-- Dossy
-- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Kris: could you elaborate on the solution that Yahoo and Google use that you'd like to see us implement?
We're not trying to shut down Flash developers, just trying to protect our users' security.
On Sun, Mar 9, 2008 at 12:37 PM, <k...@neuroproductions.be> wrote:
> @ Dossy : you can always reach the api via a server-side script on > your own domain (and put your own "allow all" crossdomain.xml in if > needed) > there is a nice php class in the docs that you can use
> @Alex,Twitter: Can't you use an other domain for the API, just like > the yahoo and google APIs ? at least check how they do it. with the > key and stuff. > Anyway, I hope it gets fixed :)
> Kris: could you elaborate on the solution that Yahoo and Google use
> that you'd like to see us implement?
> We're not trying to shut down Flash developers, just trying to protect
> our users' security.
> On Sun, Mar 9, 2008 at 12:37 PM, <k...@neuroproductions.be> wrote:
> > @ Dossy : you can always reach the api via a server-side script on
> > your own domain (and put your own "allow all" crossdomain.xml in if
> > needed)
> > there is a nice php class in the docs that you can use
> > @Alex,Twitter: Can't you use an other domain for the API, just like
> > the yahoo and google APIs ? at least check how they do it. with the
> > key and stuff.
> > Anyway, I hope it gets fixed :)
> Kris: could you elaborate on the solution that Yahoo and Google use > that you'd like to see us implement?
> We're not trying to shut down Flash developers, just trying to protect > our users' security.
1. Move the Twitter API to api.twitter.com. Use the completely permissive crossdomain.xml on api.twitter.com.
2. Stop supporting HTTP Basic auth. on api.twitter.com. Implement OAuth or some other kind of auth. token system.
3. Require non-public API requests to include a valid user auth. token.
-- Dossy
-- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
On Sun, Mar 9, 2008 at 1:51 PM, Dossy Shiobara <do...@panoptic.com> wrote:
> On 2008.03.09, Alex Payne <a...@al3x.net> wrote:
> > Kris: could you elaborate on the solution that Yahoo and Google use > > that you'd like to see us implement?
> > We're not trying to shut down Flash developers, just trying to protect > > our users' security.
> 1. Move the Twitter API to api.twitter.com. Use the completely > permissive crossdomain.xml on api.twitter.com.
> 2. Stop supporting HTTP Basic auth. on api.twitter.com. Implement OAuth > or some other kind of auth. token system.
> 3. Require non-public API requests to include a valid user auth. token.
> -- Dossy
> -- > Dossy Shiobara | do...@panoptic.com | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70)
> 2. Stop supporting HTTP Basic auth. on api.twitter.com. Implement OAuth > or some other kind of auth. token system.
Despite all the disadvantages of HTTP Basic, shutting it down completely without a transition period will break a lot of applications.
-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Why did the chicken cross the Moebius strip? To get to the other ... uh ...
