This is my current understanding of recaptcha (using v2 invisible)
We load the api.js script onto our site
We add data attributes to the button
User clicks button
A listener somewhere in the api.js script fires because it's listening for an event on a tag with those data attributes
This is where it gets fuzzy and I start guessing:
api.js gathers browsing info from the user's cookies and information about how they interacted with the site. Based on this it determines how likely you are are to be a bot and if you are below a certain threshold it gives you a test. Whether you pass the test then gets further factored into your score and all of that gets encoded into a token, which we receive in our callback that we specified on the button's data attribute.
We pass this token to the back end with the rest of our form
From the backend, we make an API request to Google to convert the token into usable information about whether the user passed or failed.
At this point I get confused about why this wasn't just what the api.js script returned in the first place. Does this step only exist in order to give Recaptcha information to further improve it? I just don't understand why this step is here, unless I'm misunderstanding what is going on earlier in the process. Am I getting these we steps wrong? Thanks.
The whole point for captchas is that your server (instead of client in the browser) can verify that the (HTTP) request it received was generated from a real person's actions, when interacting with your application.
This is why your client sends a recaptcha token to your server and your backend consults with the captcha provider about this token and receives trusted information about the original client. In this scenario, your server does not trust the client, so it receives only a token from it. Then it communicates with the trusted captcha provider server-to-server and validates that the token it received from the client is valid and the user behind it is legitimate.
If your client sent the original response from the captcha provider to your backend server, there would be no way for your server to know whether this was a legitimate response from the captcha provider, or a fake one from the client.
Related
I'm currently developing an application where holders can see historical data of their NFT's. All code is in place, but I'm still looking for a way to securely verify their ownership of a certain NFT.
There is the possibility to extend one of the dApp examples in the Elrond docs, but I'm not that familiair to React or NodeJS, so I'm trying to build this in PHP.
One thing I came across, is the login via Hooks, as used by the Maiar Exchange.
https://docs.elrond.com/wallet/webhooks/#login-hook
However, the Callback URL can be accessed manually by users, so this can give people Unauthorized access to my application.
Now, there is an undocumented extra parameter token I can pass to the Login hook (as used by Maiar Exchange). I know I can fetch a valid token by sending a POST request to 'https://id.maiar.com/api/v1/login/init'. This will give back a token I can append to the Callback URL. By doing so, the Callback URL will receive an appended signature parameter. I feel like I'm almost there, but the question is: How can I interpret this signature and how can I use this signature to verify if the returned response was valid and belongs to the given token/address? How was this signature is generated?
Also, I feel like it would be very nice if there was some sort of OAuth implementation for Elrond, but since it isn't there, I'm trying this approach.
I have been reading the OpenID Connect draft specification describing how to handle a user log off. Everything points to this super weird, two iframe solution. See here:
openid spec for sessions
and a brief description here:
Hans Zandbelt blog regarding this strategy
can someone explain why I need two separate iframes, and not just one to the openid identity provider, and some javascript on my page to delete the cookie and redirect to the sso login?
I was having the same doubts the other day about why we need two iframes to perform session check. From my point of viewing it, the RP iframe was totally useless. As a matter of fact, it's totally possible to perform the session check with just an iframe pointing to the check_session_iframe url.
The thing is that, when you receive the changed message, you will most likely want to attempt a silent token renewal, as the spec says, and you will need an iframe for doing so, hence the RP iframe.
The spec (4.1 RP Iframe) says:
Upon receipt of changed, the RP MUST perform re-authentication with
prompt=none to obtain the current session state at the OP.
When the RP detects a session state change, it SHOULD first try a prompt=none
request within an iframe to obtain a new ID Token and session state, sending
the old ID Token as the id_token_hint.
I believe the RP iframe is responsible for performing the silent token renewal, upon the receive of a changed message. The RP iframe should then generate a new token request with prompt=none, hence the silently part.
If the RP iframe fails to silently renew the token, then the user is no longer authenticated, and your application should be notified to perform proper actions.
The trigger for the deletion of your local session lives in a different domain i.e. the OpenID Connect Provider's domain. So to learn about the changes happening there you need to "poll" the Provider which involves so-called "cross-domain" communication. To avoid polling a remote URL constantly with a large network traffic overhead, the idea is that you poll for a state change locally by checking the Provider's cookie. That is done by leveraging the postMessage communication framework between iframes because only code presented by the OP can check the OP's cookie.
I am about to start working on a project, which is basically a web interface for a mobile banking application. The API is ready, I only need to provide the frontend part of the web application. I was going to make it using Backbone/Angular/Ember, but started to worry about the security.
Particularly, the following. As a rule, every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key. If I put the logic of how this param is calculated into one of .js files, anyone could potentially access some sensitive data using tools like Postman or even browser console. How should I go about this issue? I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key
I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
Yes, the server-side script would be the way to go if you do not want to expose the secret API key within your client side code or request data.
User token can (presumably) come from the user's session cookie value? So simply have a server side method that takes the method name and then returns the method_code calculated from the secret API key (kept server side only) and the user token.
The Same Origin Policy will prevent another domain making a request to your API and retreiving the method_code. I'm also assuming the API and front-end code runs on the same domain here, although if this is not the case you can use CORS to allow your front-end code to read and retreive data client-side via the API.
You can try to generate a token based on security factors and encrypt that and use it in your requests to identify your clients and valid requests.
I've been reading up on REST and there are a lot of questions on SO about it, as well as on a lot of other sites and blogs. Though I've never seen this specific question asked...for some reason, I can't wrap my mind around this concept...
If I'm building a RESTful API, and I want to secure it, one of the methods I've seen is to use a security token. When I've used other APIs, there's been a token and a shared secret...makes sense. What I don't understand is, requests to a rest service operation are being made through javascript (XHR/Ajax), what is to prevent someone from sniffing that out with something simple like FireBug (or "view source" in the browser) and copying the API key, and then impersonating that person using the key and secret?
We're exposing an API that partners can only use on domains that they have registered with us. Its content is partly public (but preferably only to be shown on the domains we know), but is mostly private to our users. So:
To determine what is shown, our user must be logged in with us, but this is handled separately.
To determine where the data is shown, a public API key is used to limit access to domains we know, and above all to ensure the private user data is not vulnerable to CSRF.
This API key is indeed visible to anyone, we do not authenticate our partner in any other way, and we don't need REFERER. Still, it is secure:
When our get-csrf-token.js?apiKey=abc123 is requested:
Look up the key abc123 in the database and get a list of valid domains for that key.
Look for the CSRF validation cookie. If it does not exist, generate a secure random value and put it in a HTTP-only session cookie. If the cookie did exist, get the existing random value.
Create a CSRF token from the API key and the random value from the cookie, and sign it. (Rather than keeping a list of tokens on the server, we're signing the values. Both values will be readable in the signed token, that's fine.)
Set the response to not be cached, add the cookie, and return a script like:
var apiConfig = apiConfig || {};
if(document.domain === 'example.com'
|| document.domain === 'www.example.com') {
apiConfig.csrfToken = 'API key, random value, signature';
// Invoke a callback if the partner wants us to
if(typeof apiConfig.fnInit !== 'undefined') {
apiConfig.fnInit();
}
} else {
alert('This site is not authorised for this API key.');
}
Notes:
The above does not prevent a server side script from faking a request, but only ensures that the domain matches if requested by a browser.
The same origin policy for JavaScript ensures that a browser cannot use XHR (Ajax) to load and then inspect the JavaScript source. Instead, a regular browser can only load it using <script src="https://our-api.com/get-csrf-token.js?apiKey=abc123"> (or a dynamic equivalent), and will then run the code. Of course, your server should not support Cross-Origin Resource Sharing nor JSONP for the generated JavaScript.
A browser script can change the value of document.domain before loading the above script. But the same origin policy only allows for shortening the domain by removing prefixes, like rewriting subdomain.example.com to just example.com, or myblog.wordpress.com to wordpress.com, or in some browsers even bbc.co.uk to co.uk.
If the JavaScript file is fetched using some server side script then the server will also get the cookie. However, a third party server cannot make a user’s browser associate that cookie to our domain. Hence, a CSRF token and validation cookie that have been fetched using a server side script, can only be used by subsequent server side calls, not in a browser. However, such server side calls will never include the user cookie, and hence can only fetch public data. This is the same data a server side script could scrape from the partner's website directly.
When a user logs in, set some user cookie in whatever way you like. (The user might already have logged in before the JavaScript was requested.)
All subsequent API requests to the server (including GET and JSONP requests) must include the CSRF token, the CSRF validation cookie, and (if logged on) the user cookie. The server can now determine if the request is to be trusted:
The presence of a valid CSRF token ensures the JavaScript was loaded from the expected domain, if loaded by a browser.
The presence of the CSRF token without the validation cookie indicates forgery.
The presence of both the CSRF token and the CSRF validation cookie does not ensure anything: this could either be a forged server side request, or a valid request from a browser. (It could not be a request from a browser made from an unsupported domain.)
The presence of the user cookie ensures the user is logged on, but does not ensure the user is a member of the given partner, nor that the user is viewing the correct website.
The presence of the user cookie without the CSRF validation cookie indicates forgery.
The presence of the user cookie ensures the current request is made through a browser. (Assuming a user would not enter their credentials on an unknown website, and assuming we don’t care about users using their own credentials to make some server side request.) If we also have the CSRF validation cookie, then that CSRF validation cookie was also received using a browser. Next, if we also have a CSRF token with a valid signature, and the random number in the CSRF validation cookie matches the one in that CSRF token, then the JavaScript for that token was also received during that very same earlier request during which the CSRF cookie was set, hence also using a browser. This then also implies the above JavaScript code was executed before the token was set, and that at that time the domain was valid for the given API key.
So: the server can now safely use the API key from the signed token.
If at any point the server does not trust the request, then a 403 Forbidden is returned. The widget can respond to that by showing a warning to the user.
It's not required to sign the CSRF validation cookie, as we're comparing it to the signed CSRF token. Not signing the cookie makes each HTTP request shorter, and the server validation a bit faster.
The generated CSRF token is valid indefinitely, but only in combination with the validation cookie, so effectively until the browser is closed.
We could limit the lifetime of the token's signature. We could delete the CSRF validation cookie when the user logs out, to meet the OWASP recommendation. And to not share the per-user random number between multiple partners, one could add the API key to the cookie name. But even then one cannot easily refresh the CSRF validation cookie when a new token is requested, as users might be browsing the same site in multiple windows, sharing a single cookie (which, when refreshing, would be updated in all windows, after which the JavaScript token in the other windows would no longer match that single cookie).
For those who use OAuth, see also OAuth and Client-Side Widgets, from which I got the JavaScript idea. For server side use of the API, in which we cannot rely on the JavaScript code to limit the domain, we're using secret keys instead of the public API keys.
api secret is not passed explicitly, secret is used to generate a sign of current request, at the server side, the server generate the sign following the same process, if the two sign matches, then the request is authenticated successfully -- so only the sign is passed through the request, not the secret.
This question has an accepted answer but just to clarify, shared secret authentication works like this:
Client has public key, this can be shared with anyone, doesn't
matter, so you can embed it in javascript. This is used to identify the user on the server.
Server has secret key and this secret MUST be protected. Therefore,
shared key authentication requires that you can protect your secret
key. So a public javascript client that connects directly to another
service is not possible because you need a server middleman to
protect the secret.
Server signs request using some algorithm that includes the secret
key (the secret key is sort of like a salt) and preferably a timestamp then sends the request to the service. The timestamp is to prevent "replay" attacks. A signature of a request is only valid for around n seconds. You can check that on the server by getting the timestamp header that should contain the value of the timestamp that was included in the signature. If that timestamp is expired, the request fails.
The service gets the request which contains not only the signature
but also all the fields that were signed in plain text.
The service then signs the request in the same way using the shared
secret key and compares the signatures.
I will try to answer the the question in it's original context. So question is "Is the secret (API) key safe to be placed with in JavaScript.
In my opinion it is very unsafe as it defeats the purpose of authentication between the systems. Since the key will be exposed to the user, user may retrieve information he/she is not authorized to. Because in a typical rest communication authentication is only based on the API Key.
A solution in my opinion is that the JavaScript call essentially pass the request to an internal server component who is responsible from making a rest call. The internal server component let's say a Servlet will read the API key from a secured source such as permission based file system, insert into the HTTP header and make the external rest call.
I hope this helps.
I supose you mean session key not API key. That problem is inherited from the http protocol and known as Session hijacking. The normal "workaround" is, as on any web site, to change to https.
To run the REST service secure you must enable https, and probably client authentification. But after all, this is beyond the REST idea. REST never talks about security.
What you want to do on the server side is generate an expiring session id that is sent back to the client on login or signup.
The client can then use that session id as a shared secret to sign subsequent requests.
The session id is only passed once and this MUST be over SSL.
See example here
Use a nonce and timestamp when signing the request to prevent session hijacking.
Disclaimer: I'm new to the REST school of thought, and I'm trying to wrap my mind around it.
So, I'm reading this page, Common REST Mistakes, and I've found I'm completely baffled by the section on sessions being irrelevant. This is what the page says:
There should be no need for a client
to "login" or "start a connection."
HTTP authentication is done
automatically on every message. Client
applications are consumers of
resources, not services. Therefore
there is nothing to log in to! Let's
say that you are booking a flight on a
REST web service. You don't create a
new "session" connection to the
service. Rather you ask the "itinerary
creator object" to create you a new
itinerary. You can start filling in
the blanks but then get some totally
different component elsewhere on the
web to fill in some other blanks.
There is no session so there is no
problem of migrating session state
between clients. There is also no
issue of "session affinity" in the
server (though there are still load
balancing issues to continue).
Okay, I get that HTTP authentication is done automatically on every message - but how? Is the username/password sent with every request? Doesn't that just increase attack surface area? I feel like I'm missing part of the puzzle.
Would it be bad to have a REST service, say, /session, that accepts a GET request, where you'd pass in a username/password as part of the request, and returns a session token if the authentication was successful, that could be then passed along with subsequent requests? Does that make sense from a REST point of view, or is that missing the point?
To be RESTful, each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP.
Okay, I get that HTTP authentication
is done automatically on every message
- but how?
Yes, the username and password is sent with every request. The common methods to do so are basic access authentication and digest access authentication. And yes, an eavesdropper can capture the user's credentials. One would thus encrypt all data sent and received using Transport Layer Security (TLS).
Would it be bad to have a REST
service, say, /session, that accepts a
GET request, where you'd pass in a
username/password as part of the
request, and returns a session token
if the authentication was successful,
that could be then passed along with
subsequent requests? Does that make
sense from a REST point of view, or is
that missing the point?
This would not be RESTful since it carries state but it is however quite common since it's a convenience for users; a user does not have to login each time.
What you describe in a "session token" is commonly referred to as a login cookie. For instance, if you try to login to your Yahoo! account there's a checkbox that says "keep me logged in for 2 weeks". This is essentially saying (in your words) "keep my session token alive for 2 weeks if I login successfully." Web browsers will send such login cookies (and possibly others) with each HTTP request you ask it to make for you.
It is not uncommon for a REST service to require authentication for every HTTP request. For example, Amazon S3 requires that every request have a signature that is derived from the user credentials, the exact request to perform, and the current time. This signature is easy to calculate on the client side, can be quickly verified by the server, and is of limited use to an attacker who intercepts it (since it is based on the current time).
Many people don't understand REST principales very clearly, using a session token doesn't mean always you're stateful, the reason to send username/password with each request is only for authentication and the same for sending a token (generated by login process) just to decide if the client has permission to request data or not, you only violate REST convetions when you use weither username/password or session tokens to decide what data to show !
instead you have to use them only for athentication (to show data or not to show data)
in your case i say YES this is RESTy, but try avoiding using native php sessions in your REST API and start generating your own hashed tokens that expire in determined periode of time!
No, it doesn't miss the point. Google's ClientLogin works in exactly this way with the notable exception that the client is instructed to go to the "/session" using a HTTP 401 response. But this doesn't create a session, it only creates a way for clients to (temporarily) authenticate themselves without passing the credentials in the clear, and for the server to control the validity of these temporary credentials as it sees fit.
Okay, I get that HTTP authentication
is done automatically on every message
- but how?
"Authorization:" HTTP header send by client. Either basic (plain text) or digest.
Would it be bad to have a REST
service, say, /session, that accepts a
GET request, where you'd pass in a
username/password as part of the
request, and returns a session token
if the authentication was successful,
that could be then passed along with
subsequent requests? Does that make
sense from a REST point of view, or is
that missing the point?
The whole idea of session is to make stateful applications using stateless protocol (HTTP) and dumb client (web browser), by maintaining the state on server's side. One of the REST principles is "Every resource is uniquely addressable using a universal syntax for use in hypermedia links". Session variables are something that cannot be accessed via URI. Truly RESTful application would maintain state on client's side, sending all the necessary variables over by HTTP, preferably in the URI.
Example: search with pagination. You'd have URL in form
http://server/search/urlencoded-search-terms/page_num
It's has a lot in common with bookmarkable URLs
I think your suggestion is OK, if you want to control the client session life time. I think that RESTful architecture encourages you to develop stateless applications. As #2pence wrote "each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP" .
However, not always that is the case, sometimes the application needs to tell when client logs-in or logs-out and to maintain resources such as locks or licenses based on this information. See my follow up question for an example of such case.