0

I am currently reviewing an web application which dose use Cookies (non authentication related) without secure flag set but uses an "background" API to retrieve authenticated data using Authorization: Bearer. For example:

GET /api/v2/admins/me/account 
HTTP/1.1 Host: www.example.com 
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 
Accept: application/json, text/plain, */* 
Accept-Language: en-US,en;q=0.5 
Referer: https://www.example.com/settings/ 
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InNlZWstand0LTIwMTcwNzIwIn0.ew0KICAiaXNzIjogIkFQSV9HYXRld2F5IiwNCiAgImp0aSI6ICJlNjYyNTgyNy0zOGM3LTRhNzgtYTc2OS01MDg1OTYwZjMzNmIiLA0KICAiZXhwIjogVlayJdLA0KICAiZW52IjogIlByb2R1Y3Rpb24iDQp9.cYEIiaJUFXqTKZyTY3riECci3ZUspyPjZ7P4uflld90OJ9IoP2XuoCM35DEhUMzC1MoFU9CNp4lJPqMSy6JkUBzKVwJrG8F439NxM2T3UMHIIkPOD7n 
Cookie: PHPSessionID=a5f9e49b-76f2-43b3-9094-a958bd472925;

Will provide me the following response:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 517
Connection: close
Cache-Control: no-cache
Content-Security-Policy: block-all-mixed-content
Date: Wed, 18 Apr 2018 21:27:51 GMT
Expires: -1
Pragma: no-cache
Server: nginx
Strict-Transport-Security: max-age=157680000

{"id":38259239, ... something important and relevant}

To my own knowledge in case of SSL cookie without secure flag set situation:

If the secure flag is set on a cookie, then browsers will not submit the cookie in any requests that use an unencrypted HTTP connection, thereby preventing the cookie from being trivially intercepted by an attacker monitoring network traffic. If the secure flag is not set, then the cookie will be transmitted in clear-text if the user visits any HTTP URLs within the cookie's scope. An attacker may be able to induce this event by feeding a user suitable links, either directly or via another web site. Even if the domain that issued the cookie does not host any content that is accessed over HTTP, an attacker may be able to use links of the form http://example.com:443/ to perform the same attack. To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic.

Would I bee able to intercept through the use of same principle or related type of attack the "Authorization: Bearer" token?

  • 1
    It's generally much easier to trick users than code. How do you expect to get it to send an unencrypted request to the api? – AndrolGenhald Apr 18 '18 at 21:43
  • @AndrolGenhald For example: I can already redirect any user to use "example.com:443/api/v2/admins/me/account" and I can already intercept PHPSessionID but i wonder if I can also intercept "Authorization: Bearer". – Lucian Nitescu Apr 18 '18 at 21:49
  • How does the application respond if the cookie is present, without the Authorization: Bearer header? – AviD Apr 18 '18 at 22:35
  • @AviD 401 Unauthorized. PHPSessionID is not an session cookie. – Lucian Nitescu Apr 18 '18 at 23:38
  • 1
    @LucianNitescu It's impossible for us to tell as it depends on the code making the requests, and whether or not you can get that code to make an unencrypted request. – AndrolGenhald Apr 19 '18 at 19:20
1

The authorization token here is not a cookie. RFC-7235, which defines the Authorization header, states that:

The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials; instead, each authentication scheme defines how the credentials are encoded prior to transmission.

So it depends on the specification of Bearer, which is RFC-6750. It states:

TLS is mandatory to implement and use with this specification.

Which tells me that it should be possible to retrieve it and more importantly, not using TLS here is a vulnurability.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.