Do you have some information regarding browsers that implement/plan to implement this part of the HTTP 1.1 specification? Additionally, what frameworks have already implemented this feature. I've done my Google research but I'd like to know if there's something else.
Also, do/would you use it? Do you find it better than the Cookie/Set-Cookie implementation?
Update: the Cookie2 specification never caught on, and RFC 6265 now declares it obsolete, making this question moot - though it's possibly still interesting to see a discussion of why it failed.
The answer below was written in 2009.
I'll mainly answer the second part.
I did some research into it recently and am now firmly of the opinion that no, it is not ready for use, and I would not use it.
Finding concrete data on the existing specification that will work with current browsers and proxies is difficult, because cookies started out as a proprietary browser extension and continue to have proprietary features added, like the most recent "http-only" flag. I think by and large the industry has continued to use this quasi "Netscape-style" mixed with RFC 2109 implementation, except with more loose rules about third-party cookies and some strange behaviour sometimes with non-quoted strings.
As for whether I find it better, a read through of the spec does certainly show its benefits - ie, the client now passes back the path, domain and port parameters as 'dollar' parameters, so a web app knows what parameters to use to delete/overwrite that cookie. The ability to store comments with the cookies will be a win for the user one day, so they get the chance to see a plain text explanation of what the cookie is for, but unless browsers start warning people about cookies, who is going to see them?
The need to send both a set-cookie and set-cookie2 header also upset the purist in me, as did the need for a client to send a Cookie2 header in addition to the Cookie header, which seemed unnecessary when I looked at it. YMMV.
Read RFC 6265 which obsoletes rfc 2965. It has advice not to use or implement cookie2
The current state is that most browser only fully support the initial Cookie specification by Netscape.
Set-Cookie/Cookie per RFC 2109 are only supported by some browser (I don’t know which) and Set-Cookie2/Cookie2 per RFC 2965 only by Opera.
Related
According to wikipedia the two mentioned request/correlation id headers aren't standard. As far as I know they are extremely helpful in tracing API requests from client to server (and additional applications).
I have seen this recommended to be used in may articles online - yet it's not an official standard.
Is there some reason that this shouldn't be used?
If these headers are good for general use, it simply means that nobody has gone through the trouble of standardizing them. Anyone can pick this up, but someone has to.
According to RFC 6648 which has deprecated the 'X-' convention, there is no reason to prefix custom headers like API key with 'X-' for designing web API now.
In spite of RFC standard, I wonder that it is really safe to conform the new convention, without 'X-'. Someone says that some browsers or even some ISPs which follow the old convention may block such headers which follow the new convention by reason of non-standard but I couldn't confirm that yet.
The solution would be simple, supporting both conventions or old convention only. Though, regardless of the solution, I'd like to know if it is safe or not to conform the new convention or is a question with no answer.
My question is pretty simple:
If you have two web-application components:
Server-side (secret-capable) code in PHP, Python, Perl ... whatever
The javascript output and interpreted by the browser
Given a single redirection to the authorisation endpoint (and back) is it possible to specify and transfer the information for:
An authorization code grant (for the server-side code)
An implicit grant with restricted rights for the Javascript
thereby transferring the two grants (one in the request-url proper and the other in the fragment) in one round-trip without violating the RFC?
One redirect-loop seems cleaner than one for each grant (even if the second doesn't block due to previous authorization)
Thanks in advance!
References
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-16#section-4.2
edit 1: code_and_token seems to be the type of thing I am after ... an auth code grant for the server to request the access code using its credentials ... and an implicit token for the javascript. As mov matake mentions, it was pulled from the RFC after v11, with no real note as to why. Facebook and Google seem to support this which makes me suspect it will return.
The token_and_code request type was removed from the specification because it needed significant work in terms of security analysis and rules, and no one offered to do it. It was originally proposed by a Twitter engineer who left the working group shortly after.
It will not be added to the specification, but it can easily be introduced by an extension. Google supported this flow on the list, but later said they will not implement it, and instead, will implement something else using HTML5 features.
OAuth 2.0 had "code_and_token" response type before (might be "token_and_code").
But it had been removed from the spec later.
So in current spec, if you need code for your server, the way will be
use "code" response type
get an access token on server side
and give it to the client side
You can't get scope-restricted token only for client side though..
Or you might set up an proxy on your server side for your client side code.
http://www.ietf.org/mail-archive/web/oauth/current/msg04969.html and http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html
says that the "code_and_token" type was good, but the RFC didn't make it clear enough that the token in the fragment (for Javascript) should/could have less rights than the token obtained by the access code...
Thanks Nov Matake for pointing out the code_and_token type was part of the spec (at one point) as I missed it in the old specification versions (though it is widely implemented).
Looks like it will make a comeback though, as it is quite well supported by existing implementations at Google and Facebook and seems to be a core request to support both user-agent tokens and server-side access codes in one round trip.
The problem seems to be defining the semantics of "scope" in this context as well as defining a degree to which scope can differ in a single request. It makes sense that the user-agent token has limited rights, ie not the same rights as the client application.
We shall wait and see ... the downside of implementing off the back of an involving RFC.
I just got hammered on a Security Audit by Deloitte on behalf of SFDC. Basically we use flex and communicate via AMF. We use FluorineFX for this (as opposed to LCDS and Blaze). We are being told that because the AMF response is not encoded and that someone can manipulate the AMF parameters and insert Javascript that this is a XSS vulnerability. I'm struggling to understand how the AMF response back, which could echo the passed in JS in an error message, can be executed by the browser or anything else for that matter. I'm quite experienced with XSS with HTML and JS but seeing it get tagged with AMF was a bit of a surprise. I'm in touch with FluorineFx team and they are perplexed as well.
I'd be surprised to see an AMF library encode the response data, Fluorine surely does not. It would seem though that security applications like PortSwigger and IBM AppScan are including this type of test in their tool chest. Have you run into this vulnerability with AMF and can you explain how the XSS issue can manifest itself? Just curious. I need to either argue my way out of this if an argument exists or patch the hole. Given the AMF usage with Flex I thought you might have some insight.
Additional information ...
So A little more on this from the actual vendor, PortSwigger. I posed the question to them and net, net, they concede this type of attack is extremely complicated. Initially they are classifying this as a High Severity security issue but I think their tune is changing now. I thought I'd post the content of their response for you all as I think the perspective is interesting none-the-less.
--- From PortSwigger on the issue ---
Thanks for your message. I think the answer is that this is potentially a
vulnerability, but is not trivial to exploit.
You're right, the issue wouldn't arise when the response is consumed by an
AMF client (unless it does something dumb), but rather if an attacker could
engineer a situation where the response is consumed by a browser. Most
browsers will overlook the HTTP Content-Type header, and will look at the
actual response content, and if it looks at all like HTML will happily
process it as such. Historically, numerous attacks have existed where people
embed HTML/JS content within other response formats (XML, images, other
application content) and this is executed as such by the browser.
So the issue is not so much the format of the response, but rather the
format of the request required to produce it. It's not trivial for an
attacker to engineer a cross-domain request containing a valid AMF message.
A similar thing arises with XML requests/responses which contain XSS-like
behaviour. It's certainly possible to create a valid XML response which gets
treated by the browser as HTML, but the challenge is how to send raw XML in
the HTTP body cross-domain. This can't be done using a standard HTML form,
so an attacker needs to find another client technology, or browser quirk, to
do this. Historically, things like this have been possible at various times,
until they were fixed by browser/plugin vendors. I'm not aware of anything
that would allow it at the moment.
So in short, it's a theoretical attack, which depending on your risk profile
you could ignore altogether or block using server-side input validation, or
by encoding the output on the server and decoding again on the client.
I do think that Burp should flag up the AMF request format as mitigation for
this issue, and downgrade the impact to low - I'll get this fixed.
Hope that helps.
Cheers
PortSwigger
--- more info on audit ---
what portSwigger does is not necessarily mess with binary payload, what they do is mess with the actual AMF parameters that are posted to the handler to direct the request. For example here is a snippet from the audit and it shows part of the AMF response to a request ...
HTTP/1.1 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
P3P: CP="CAO PSA OUR"
Content-Type: application/x-amf
Vary: Accept-Encoding
Expires: Tue, 06 Apr 2010 18:02:10 GMT
Date: Tue, 06 Apr 2010 18:02:10 GMT
Connection: keep-alive
Content-Length: 2595
......../7/onStatus.......
.SIflex.messaging.messages.ErrorMessage.faultCode.faultString
.faultDetail.rootCause.extendedData.correlationId.clientId.destination
.messageId.timestamp.timeToLive body.headers.#Server.Processing..kFailed
to locate the requested type
com.Analytics.ca.Services.XXX5c2ce<script>alert(1)</script>9ccff0bda62..
....I506E8A27-8CD0-598D-FF6E-D4490E3DA69F.Id95ab281-d83b-4beb-abff-c668b9fd42d5
..fluorine.I04165c8e-f878-447f-a19a-a08cbb7def2a.A.q..#............
. DSId.Aeb5eeabcbc1d4d3284cbcc7924451711.../8/onRes
...[SNIP]...
note the "alert" script in there ... what they did was appended some script enclosed JS to one of the parameters that are passed containing the method to call namely 'com.Analytics.ca.Services.XXX'. By doing so the JS came back in an error message but there are a lot of things that would have to happen for that JS to get anywhere close to executing. Seems an indirect threat at best.
-- Security Auditor's latest perspective --
I’ve discussed with the larger team and we all believe it’s a valid attack. As PortSwigger mentions in his first paragraph, while theoretically since you set the content-type to x-amf, and would hope it won’t render in the browser, most browsers will ignore this request and render it anyway. I think the vendors are relying heavily on the fact that the content-type is set; however popular browsers like IE and some versions of Safari will ignore this.
The attack can easily be triggered by exploiting CSRF or any other form of initiating an XSS attack.
It could not be a JavaScript injection, as what in the Flash Player would interpret JS? The flash community would be ecstatic if we had native JS or even json support in the player. There is no eval function for actionscript let alone javascript
Let's assume they meant you could inject it with actionscript. The AMF protocol does not send code, it sends data models in the form of primitive types or generic or typed objects. The worst thing that could happen is that they analyze your model and add additional data. This would be amazingly difficult to do as you would not be able to inject the data but would have to parse all the data, add the new data, parse it back and keep the AMF headers. Because AMF uses references in it's data serialization which means that when duplicate object types you would have had to of seen the first object. The reference is then an offset which means little chance of adding code but only changing values to existing parameters.
The remote object has a response handler that is checking for the data types and expects to bind those data types to ui components or whatever your code does. If those data types are wrong you will get an error. If the AMF response sequence number is wrong you will get an error. If anything is not perfectly formed in the amf datagram you will get an error.
Remote object automatically retry. If the "injecting" code takes to long Flex will resend a message and invalidate the one that took to long.
Just my two cents. As an AMF developer I have frequently wished it was easy to screw with the amf datagram for debugging and testing. Unfortunately you will get an error.
Wade Arnold
You seem to have answered your own queries here.
So you have a server side implementation that takes the arguments to an amf function call and includes the input data somewhere in the returned output.
I appreciate that this is largely a theoretical attack as it involves getting the payload to be rendered by the browser and not into an amf client. Other vulnerabilities in browsers/plugins may be required to even enable this scenario. Maybe a CSRF post via the likes of a gateway.php or similar would make this pretty easy to abuse, as long as the browser processed the output as html/js.
However, unless you need the caller to be able to pass-through angle brackets into the response, just html-encode or strip them and this attack scenario dissapears.
This is interesting though. Normally one would perform output-encoding solely for the expected consumer of the data, but it is interesting to consider that the browser could often be a special case. This really is one hell of an edge-case, but i'm all for people getting into the habit of sanitising and encoding their untrusted inputs.
This reminds me, in many ways, to the way that cross-protocol injection can be used to abuse the reflection capabilities of protocols such as smtp to acheive XSS in the browser. See http://i8jesus.com/?p=75
I can't explain how someone would take advantage of this "vulnerability".
But, can you solve the issue to their satisfaction by passing data over an HTTPS connection instead of straight HTTP? Assuming you have an SSL certificate installed on your server and HTTPS enabled, this should be a minor change in the services-config.xml file that you compile into your Flex Application.
I pinged an Adobe colleague of mine in hopes that he can offer more insight.
I think it is a valid attack scenario. A related attack is GIFAR, where the JVM is fooled to treat a gif file as a jar. Also, I don't think output encoding is the right way to solve the problem.
The premise of the attack is to fool the browser into thinking the AMF response is HTML or Javascript. This is possible because of a feature called MIME Type Detection, which is essentially the browser saying "Developers may not know about content-types, I will play god and (possibly incorrectly) figure out the MIME type".
In order for this to work, the following need to hold true -
The attacker should be able to make a GET or POST request to your AMF server using HTML techniques like <script> or <frame> or an <a> tag. Techniques like XmlHttpRequest or Flash or Silverlight don't count.
The attacker should be able to insert malicious content into the first 256 or so bytes of the response. Additionally, this malicious content should be able to trick the browser in thinking that the rest of the response is really javascript or html.
So, how do you prevent it?
It is best to ensure the attacker cannot make a request in the first place. A very simple and effective way is to add a http request header while making the AMF request, check its existence on the server and deny the request if absent. The value can be a hard-coded value and need not be secret. This works, because there is no known method of adding a custom request header via standard html techniques. You can do so via XmlHttpRequest or flash or silverlight, but then the browser will not interpret the content-type for you, so its okay.
Now, I don't know much about AMF, but if it is already adding a request header - then this attack scenario is not possible. If it isn't, its trivial to add one.
HTML escaping the content is not a good solution. Allegedly, there are various ways to trick the browser into thinking the response is actually HTML. In other words, the malicious input need not be well formed HTML. Try a google search on mime sniffing, you should be able to find various ways to trick the browser.
I don't know how possible it is to alter data within an AMF response stream, but you might want to ensure that your endpoints cannot be manipulated through communication with the browser and/or JavaScript. Check out this article under the Malicious data injection section.
I'm looking for all the current standard header values a web server would generally receive. An example would be things like "what will the header look like when coming from a Mac running OS X Leopard and Camino installed?" or "what will the header look like when coming from Fedora 9 running Firefox 3.0.1 versus SuSe running Konqueror?"
PConroy gave an example from JQuery tending towards what I'm looking for. What I want though are the actual example headers.
Did you try the RFC? It has all that information.
Actually, when searching for information on any protocol or standard, try to search for the RFC first.
Cheers.
With regards to user-agent, that is entirely up to the creator of the application. See this semi tongue-in-cheek history of user-agent. In summary, there really isn't a canonical set of values. Microsoft based user-agents may change based on software installed on the local machine (version of .NET framework, etc).
There is no set-in-stone list of user agent values. You can find lengthy lists (such as this one used by the JQuery browser plugin).
Regarding other HTTP Headers, this wikipedia article is a good place to start.
IANA keeps track of HTTP headers
IANA is responsible for maintaining many of the codes and numbers contained in a variety of Internet protocols, enumerated below. We provide this service in coordination with the Internet Engineering Task Force (IETF).
Which includes:
Message Headers
Permanent Message Header Field Names
Provisional Message Header Field Names
Here's the exhaustive list which was originally based on RFC 4229
For the user agent, a quick google search pulled up this site.
The list of HTTP headers is easily available on the W3 website:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
PConroy also linked to the wikipedia page, which is more concise, and a little easier formatted:
http://en.wikipedia.org/wiki/List_of_HTTP_headers
However, the "User-Agent" header is a bad example, since there's no set response; the user-agent string is decided by the client so it can literally be anything. There's a very comprehensive List of User Agents available, but it's not necessarily going to cover any possible option, since even some toolbars and applications can modify the user-agent for Internet Explorer or other browsers.
The chipmunk book from O'Reilly is good as is Chris Shiflett's HTTP reference.
Oh, whoops, it's not a chipmunk. It's a thirteen-lined ground squirrel.