• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 369
  • Last Modified:

authenticating a REST call when there is already a session

Hi Experts,

I'm interested in hearing my options when I have a REST API that any authenticated individual can call.  Basically, there's an ID that's reused across multiple REST calls and anyone looking at the URL can do injection attacks on it (if they are authenticated of course).

Any options or best-practices that exist for this?

Many thanks,
Mike
0
thready
Asked:
thready
  • 4
  • 4
1 Solution
 
Dave BaldwinFixer of ProblemsCommented:
I'm not sure I understand the question.  Anyone who authenticates looks like a legitimate user.  Besides the normal user logouts and session timeouts, what are you looking for?
0
 
threadyAuthor Commented:
The unique ID used in the REST call is one used during that session, assigned by the server with a previous get from the client.  The rest API can be tampered with if someone sniffs URLs coming from a legitimate user (from another badly behaving legitimate user who's logged in.)  Since anyone can see that unique ID, another user can make a REST call with it with bad data and it would break the behavior of the API...  please let be know if this is still not so clear...
Thanks!
Mike
0
 
threadyAuthor Commented:
Basically, URLs are not encrypted over HTTPS, so anyone can see that ID.  presumably, all you would need to do to break this REST API would be to use it maliciously...  by logging in and using someone else's ID...  from their own API call...
0
Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

 
Dave BaldwinFixer of ProblemsCommented:
You can not distinguish two users who use legitimate logins.

http://en.wikipedia.org/wiki/Representational_state_transfer

This RFC http://tools.ietf.org/html/rfc2818 says that only the server name is sent in the clear to make a TLS connection and that everything else including the actual URL and headers are sent encrypted.
0
 
threadyAuthor Commented:
Where does the rfc say that only the server name is sent in the clear? I can't find that anywhere...
0
 
Dave BaldwinFixer of ProblemsCommented:
Note "a connection to the server".
2.1. Connection Initiation


   The agent acting as the HTTP client should also act as the TLS
   client.  It should initiate a connection to the server on the
   appropriate port and then send the TLS ClientHello to begin the TLS
   handshake. When the TLS handshake has finished. The client may then
   initiate the first HTTP request.  All HTTP data MUST be sent as TLS
   "application data".  Normal HTTP behavior, including retained
   connections should be followed.
That is also what I see in Fiddler.
0
 
threadyAuthor Commented:
Kick-ass answer.  Thanks a lot!  awesome.
0
 
Dave BaldwinFixer of ProblemsCommented:
You're welcome, thanks for the points.
0

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now