I realized that once a user logs into the application and receives an Auth token there is the potential that they could use that token along with a rogue client to exploit an endpoint that they now have access to.

For example, they can make a million garbage posts or attempt to like something up a thousand times(trivial examples but you get the point)


What strategies can we use to guard against this type of exploitation from a malicious user and keep the endpoints use to what it was intended for?

  • 2
    Sounds like you're looking for a CSRF token - essentially, sending a value from the server to be returned with a subsequent request, and ignoring any requests that either don't have a token, or that have a token which has already been used. – Matthew Mar 21 '16 at 16:28
  • So I would send that token to any part of the client application that would make the legitimate http request and ignore any request that comes without that token? Couldn't that token be just as easily abused as the Auth token though? – Nick Pineda Mar 21 '16 at 16:37
  • 1
    @Matthew it's a little confusing using a CSRF Token as well because I thought they were used to protect against an entirely different attack - "Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated." – Nick Pineda Mar 21 '16 at 16:40
  • 1
    It's a one-use token, in this case - the auth token validates that the user has rights to access a given endpoint, and the CSRF token ensures that one request requires one response. You can easily restrict provision of CSRF tokens to an acceptable speed level, on the server side. In this case, it's a malicious program (rogue client) which you're protecting against. – Matthew Mar 21 '16 at 16:41
  • 1
    No, they work as any method which isn't automatically sent - adding a token to an AJAX request is fine. The hidden field thing is a residue of them being used for standard form requests. – Matthew Mar 21 '16 at 17:01

For your examples you'd need a throttling mechanism in your application which checks some preconditions like the timestamp of the last user activity before the request is processed.

However there's no general purpose measure which prevents all misuse of your application. You must analyze the use-cases in your application and think about how the functionality could be exploited in order to develop and deploy security controls. A penetration test could help with this.

Your current approach sounds a bit like candy security (Authentication as single security layer).

| 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.