0

Try to expose protected REST API without exposing credentials in the Client (JS Code).

All solutions that come to my mind, can be reversed and the Attacker can reconstruct them.

Are there any proven solutions? Best practices?

Ideas, I came up for example:

  1. Obfuscating credentials

  2. Hashing client side set of elements and comparing server side to make sure the Client is untouched (not used by the Attacker)

can be reversed.

Unfortunately, HTTPS authentication does not come into play, since the website accessing the REST API (Client, JS Code) should be open to the public. I cannot request each Client (Website visitor) to request a PKC (Public Key Certificate)

HTTPS Client Authentication

HTTPS Client Authentication requires the client to possess a Public Key 
Certificate (PKC). 
If you specify client authentication, the web server will authenticate the 
client using the client’s public key certificate.
HTTPS Client Authentication is a more secure method of authentication than 
either basic or form-based authentication. It uses HTTP over SSL (HTTPS), 
in which the server authenticates the client using the client’s Public Key 
Certificate (PKC). Secure Sockets Layer (SSL) technology provides data encryption,
server authentication, message integrity, and optional client authentication for a 
TCP/IP connection. You can think of a public key certificate as the digital 
equivalent of a passport. It is issued by a trusted organization, which 
is called a certificate authority (CA), and provides identification for 
the bearer.

I want to prevent that people will obtain credentials and scrape/perform many request to REST API.

I guess, our only solution is than IP based throttling? To punish bad Clients.

Thanks in advance!

Update 1:

After Discussions with @ThoriumBR, came up with this solution. Not optimal but should be better than nothing.

Design:

Client Website <-> New API (Proxy) <-> Old API

Flow:

Wrap old API (private) against new API (public, in diagram above Proxy)

1) Client Website makes Request to Proxy

2) Proxy Sends CAPCHA back

3) Client Website complete CAPCHA

4) Proxy creates JWT (assign capcha intrval in JWT for example as 10 (capcha_int:10), assign deviceid: fingerprint (to know the users from the same IP)) sends it back to Client Website. Proxy checks also for abuse, if deviceid is misbehaving, it will be blocked.

5) Website Send request to Proxy with JWT

6) Proxy check JWT, if capcha interval (capcha_int) is equal 10 send CAPCHA, resets it, if it misbehaves, if not, sends request to old API

7) old Api sends reponse via Proxy to Client Website

IPs will be IP based Throttled for abuse. (second layer to prevent abuse)

  • How about using a proxy on the server, and JWT to authenticate the clients? – ThoriumBR Aug 20 '18 at 13:13
  • But don't the client would need to somehow authenticate to JWT ... so I have to expose JWT auth, which the Attacker/Malicious user can redo. So I get to the same scenario .... No? – dev Aug 20 '18 at 13:19
  • 1
    Let us continue this discussion in chat. – ThoriumBR Aug 20 '18 at 14:22
  • 1
    you have to put the API behind your site, typically with a php relay script, otherwise you'd have to share your credentials with every visitor. – dandavis Aug 20 '18 at 18:24
  • 1
    @android_dev Then I suspect you're out of luck, without having some kind of login/authentication for you normal visitors. Essentially (as I think I understand it), anything you do in the browser to "prove" it's your JS making the API calls can be duplicated by an attacker (including returning hashes of client-side elements etc.). – TripeHound Aug 22 '18 at 9:09

Your Answer

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

Browse other questions tagged or ask your own question.