0

I was reading that it was a good idea to convert all GET type requests to a json resource to POST in order to prevent another site from stealing information through <script src="myEndpoint"> but I'm still trying to make sense of it. It seems that this would would only protect against that scenario or possible enumeration of the endpoint.

I am planning for our json resources to require an auth token in the auth header in order for the action to execute and return JSON. Should this be good enough?

Sinaesthetic
  • 9,847
  • 25
  • 95
  • 165
  • No. Others can still hijack using the auth token passed by your trusted clients. If the information is sensitive, always hide JSON version of it behind POST, not GET. – danludwig Jan 13 '14 at 22:36
  • The information isn't that sensitive,just numbers with no identifying information. At least none that could be used without a token. It seems to me that if the token was hijacked, then I have deeper problems. However, I don't see what that has to do with a json resource and the GET verb – Sinaesthetic Jan 13 '14 at 23:16
  • See this: http://haacked.com/archive/2009/06/25/json-hijacking.aspx/ ...and think of your access token as being the same security measure as the authentication cookie. This may also help: http://stackoverflow.com/questions/8464677/why-is-jsonrequestbehavior-needed/8464685#8464685 – danludwig Jan 13 '14 at 23:22
  • JUST got done reading it and I get it now I think. I misunderstood what you meant by trusted clients. Basically, the attacker rewrites your js object setter by tricking you into loading a page with a script, so that when the response object is being built, it could post info to the attacker. interesting – Sinaesthetic Jan 13 '14 at 23:25
  • So again, if the data is not public, don't worry about it -- GET JSON all day long. If it is not public, only return JSON data in response to POST requests, not GET. – danludwig Jan 13 '14 at 23:28

0 Answers0