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 ...
> > 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.
Never mind -- I read this as twitter.com, not api.twitter.com.
-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- "I would blame Microsoft even if it *weren't* their fault." -- me ----------
I like OAuth for webservices talking to other webservices, it's really nice stuff. But I have doubts if users of desktop applications will like it to be redirected to a browser first before they can use it.
Are you thinking about supporting only OAuth for API access, dropping Basic Auth?
On Sun, Mar 9, 2008 at 11:12 PM, Cameron Kaiser <spec...@floodgap.com> wrote:
> > > 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.
> Never mind -- I read this as twitter.com, not api.twitter.com.
> -- > ------------------------------------ personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- "I would blame Microsoft even if it *weren't* their fault." -- me > ----------
On 2008.03.09, Marco Kaiser <kaiser.ma...@gmail.com> wrote:
> Are you thinking about supporting only OAuth for API access, dropping Basic > Auth?
You have to drop HTTP Basic auth--that is exactly where the security issue arises from. Once the browser captures the auth. credentials from the user, it always sends them, thus allowing third-party sites to generate requests in the browser, via Flash, as the user, which can be used for malicious purposes.
-- 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)
They "have to"? Wow... Maybe they should decide themselves?
By the way, I'm not talking about accessing the API from a browser, but in desktop clients. There is no 3rd-party-site involved. I'd be happy if basic auth or any other mechanism that does not require the user to be redirected to a browser would only be available over SSL, though.
On Sun, Mar 9, 2008 at 11:31 PM, Dossy Shiobara <do...@panoptic.com> wrote:
> On 2008.03.09, Marco Kaiser <kaiser.ma...@gmail.com> wrote: > > Are you thinking about supporting only OAuth for API access, dropping > Basic > > Auth?
> You have to drop HTTP Basic auth--that is exactly where the security > issue arises from. Once the browser captures the auth. credentials > from the user, it always sends them, thus allowing third-party sites to > generate requests in the browser, via Flash, as the user, which can be > used for malicious purposes.
> -- 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 2008.03.09, Marco Kaiser <kaiser.ma...@gmail.com> wrote:
> They "have to"? Wow... Maybe they should decide themselves?
True. The choices are: keep things the way they are and lock out third-party developers from using Flash or force them to go through a proxy; OR, make the changes I mentioned.
It sounds like Alex is hinting that they're opting to do the latter, not the former. We'll see.
-- 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 Mon, Mar 10, 2008 at 12:42 AM, Dossy Shiobara <do...@panoptic.com> wrote:
> On 2008.03.09, Marco Kaiser <kaiser.ma...@gmail.com> wrote: > > They "have to"? Wow... Maybe they should decide themselves?
> True. The choices are: keep things the way they are and lock out > third-party developers from using Flash or force them to go through a > proxy; OR, make the changes I mentioned.
> It sounds like Alex is hinting that they're opting to do the latter, not > the former. We'll see.
> -- 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)
> > Are you thinking about supporting only OAuth for API access, dropping Basic > > Auth?
> You have to drop HTTP Basic auth--that is exactly where the security > issue arises from. Once the browser captures the auth. credentials > from the user, it always sends them, thus allowing third-party sites to > generate requests in the browser, via Flash, as the user, which can be > used for malicious purposes.
If you mean completely remove HTTP Basic Auth from the entire API specification and make OAuth the only method, though, I would *not* support that. That would break too many clients, and there are lots of one-off scripts that use the easy method of passing auth headers (including over SSL).
-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- PowerPC inside! ------------------------------------------------------------
On 2008.03.10, Marco Kaiser <kaiser.ma...@gmail.com> wrote:
> I bet there are some other choices between the two you think of... not > just black and white. But yes, we will see.
There are other choices, but none of them involve allowing HTTP Basic auth. That is precisely the core of the security issue. SSL wouldn't help here, either.
-- 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)
> > > Are you thinking about supporting only OAuth for API access, dropping > Basic > > > Auth?
> > You have to drop HTTP Basic auth--that is exactly where the security > > issue arises from. Once the browser captures the auth. credentials > > from the user, it always sends them, thus allowing third-party sites to > > generate requests in the browser, via Flash, as the user, which can be > > used for malicious purposes.
> If you mean completely remove HTTP Basic Auth from the entire API > specification and make OAuth the only method, though, I would *not* > support > that. That would break too many clients, and there are lots of one-off > scripts that use the easy method of passing auth headers (including over > SSL).
On Mon, Mar 10, 2008 at 2:11 AM, Marco Kaiser <kaiser.ma...@gmail.com> wrote: > Cameron, I absolutely second that.
> On Mon, Mar 10, 2008 at 2:43 AM, Cameron Kaiser <spec...@floodgap.com> > wrote:
> > > > Are you thinking about supporting only OAuth for API access, dropping > Basic > > > > Auth?
> > > You have to drop HTTP Basic auth--that is exactly where the security > > > issue arises from. Once the browser captures the auth. credentials > > > from the user, it always sends them, thus allowing third-party sites to > > > generate requests in the browser, via Flash, as the user, which can be > > > used for malicious purposes.
> > If you mean completely remove HTTP Basic Auth from the entire API > > specification and make OAuth the only method, though, I would *not* > support > > that. That would break too many clients, and there are lots of one-off > > scripts that use the easy method of passing auth headers (including over > > SSL).
On Mon, Mar 10, 2008 at 8:10 PM, Alex Payne <a...@al3x.net> wrote:
> We're not going to remove Basic Auth from the Twitter API without a > very, very long grace period and plenty of conversations with this > group.
> On Mon, Mar 10, 2008 at 2:11 AM, Marco Kaiser <kaiser.ma...@gmail.com> > wrote: > > Cameron, I absolutely second that.
> > On Mon, Mar 10, 2008 at 2:43 AM, Cameron Kaiser <spec...@floodgap.com> > > wrote:
> > > > > Are you thinking about supporting only OAuth for API access, > dropping > > Basic > > > > > Auth?
> > > > You have to drop HTTP Basic auth--that is exactly where the security > > > > issue arises from. Once the browser captures the auth. credentials > > > > from the user, it always sends them, thus allowing third-party sites > to > > > > generate requests in the browser, via Flash, as the user, which can > be > > > > used for malicious purposes.
> > > If you mean completely remove HTTP Basic Auth from the entire API > > > specification and make OAuth the only method, though, I would *not* > > support > > > that. That would break too many clients, and there are lots of one-off > > > scripts that use the easy method of passing auth headers (including > over > > > SSL).
Ed: OAuth is the next authentication mechanism we'll be adding to the API.
On Mon, Mar 10, 2008 at 2:31 PM, Ed Costello <epcoste...@gmail.com> wrote: > On Mon, Mar 10, 2008 at 3:10 PM, Alex Payne <a...@al3x.net> wrote:
> > We're not going to remove Basic Auth from the Twitter API without a > > very, very long grace period and plenty of conversations with this > > group.
> Would you consider adding digest authentication and gracefully migrating to > that? > -- > -ed costello > Artific Industries, e...@artific.com, http://artific.com/
|
