I can't understand why I need to validate user response on server side in recaptcha v2? Is just checking on client side sufficient? I suspect that server side validation is also important as otherwise recaptcha is just a checkbox.
Which bring me to my other question - How is recaptcha not different from just a checkbox?
I can't understand why I need to validate user response on server side in recaptcha v2?
An attacker could make an HTTP request to your server-side code that completely bypasses all your client-side code, including the CAPTCHA.
How is recaptcha not different from just a checkbox?
It applies a large collection of heuristics measured with JavaScript and then generates a custom value.
It isn't a simple true/false that can be determined just by scraping a page.
Related
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.
I am curious if anyone has a solution to this unique situation as I have a solution currently, though I feel it is not the most optimal.
The Situation.
I have built an MVC style web application that talks to a web API through http (authenticating via JWT). My web application is secured by appending authorization to its view controllers and redirecting to a Microsoft login endpoint - then directing back to the view where whichever given controller/function handles the request, connects to the API, appends data to the view, etc.
Preferably I would like to use JQuery/Ajax to submit http requests client-side and update a given view with whatever data the user may wish to see relative to the webpage they're on. This way I could control exactly what the user should see landing on the page any which way and submitting requests from web app to API. Also would enable better continuity between requests as there isn't actually a full refresh of the view. All in all it is my line of thought that this execution would lead to a nice user experience.
The Problem.
So the big issue that I have had to circumvent is CORS Policy. I initially attempted to use JS just as I said above but requests would be redirected to the login endpoint and blocked due to there being no CORS header appended to the request.
'So include a policy in your application and append an authorized header to your Ajax outgoing request' you might say, well... you cannot override CORS security around Microsoft's login endpoint.
My Solution.
What I have done simply instead is create HTML Forms around fields the user would pick and chose to specify what data they wanted from the API. Then carry over input data to the returned view via 'ViewData'
and using razor pages of course I can actually initialize JS variables via C# input.
Side Note
I use JS to transform the API data into graphs for the user to see. I am doing this with a JavaScript Library.
My Question to you.
This all leads me to ask then, is there a way to dynamically update a view without using JS? I require a method that can hit the login redirect without being blocked because the request initiated client-side.
Every solution I am aware in some way, shape, or form utilizes JS to make the request. So I am at a loss for how to truly get the functionality I am after without having my requests get blocked due to CORS Policy.
Thanks in advance y'all.
I'm using google recaptcha V2
Is there any way to set trust IPs - ips that will not require to check the "i'm not rebot" checkbox ?
If you are doing a client side validation of the trusted IPs it would break the whole point in having captcha since the function may be overridden.
If you are serving the form from your server and if it is server-side rendered, things may be easy and you could avoid using captcha by modifying the form appropriately in your server. The exact code may vary based on your stack.
If you want to implement this using some other REST service, you can employ multiple strategies. One could be to request a token from your service and based on the IP whitelist you generate and send a new token which can be used to replace the captcha in the front end. But in this case, you must do an extra validation to check if the token is valid and from the same IP as the one requested.
In any case, I am not sure if there is a straight forward mechanism that would give you the same level of security as a Captcha that sets trusted IPs without some server side magic.
Let's say I've got a var generated on the fly (e.g. a Facebook API call which returns the user ID). I then want to send this var to my own server using jQuery's AJAX.
My question - is this secure? Could someone intercept and insert their own value before the AJAX is sent to my server? If this is not secure how does one go about doing such AJAX posts?
Yes, someone could intercept it and change the value unless you use HTTPS. So that would basically be the solution to making that secure, along with an authentication system of some sort. Other than that, make sure you don't store anything secret in that var as your users could easily see the value of that.
Verify/Pull the ID server side e.g http://graph.facebook.com/1303834107 :)
Could someone intercept and insert their own value before the AJAX is sent to my server?
That depends on who you mean by "someone".
If you are talking about a third party attacker, then possible attack points are:
Between Facebook's server and the browser. If you have the option to use SSL for that request, then that is the only way to can protect it there.
Inside the user's browser. This requires that the attacker has already compromised the user's computer. There is nothing you can do about this.
Between the browser and your server. Use SSL to defend against this.
If you are talking about the user of the browser, then there is nothing you can do to stop them changing the data. The user is in total control of what their browser sends to your server. The only defence you have is taking their browser out of the equation (which would involve using OAuth to get permission to access their Facebook account from your server).
My question is that suppose, in my web app, I use ajax to call upon methods on the server side, isn't it creating a security hole in the app? Like, say I have an option for the user to deactivate the account, which can be done by clicking a button. This is done via Ajax.
So, can't a hacker send a request to the server to deactivate the account instead of the user?
HELP!!!
My question is that suppose, in my web app, I use ajax to call upon methods on the server side, isn't it creating a security hole in the app?
From a security perspective, there is no difference between an HTTP request that involves JavaScript and one which doesn't (e.g. that uses a regular form, or is handcrafted).
… but you can't call methods from the client, you can only make requests to URIs. The server might cause a method to be called based on receiving a request to a specific URI.
So, can't a hacker send a request to the server to deactivate the account instead of the user?
They could, which is why you need (trustworthy) authentication / authorisation and CSRF protection (just like you would for a request to disable an account that didn't involve Ajax).
This is not a problem with AJAX alone, but with any arbitrary HTTP request that wants to authenticate/maintain a session. The user needs to be authenticated in some way in order to make requests, this is usually done with cookies. Using AJAX does not make the matter any worse though because it is still a HTTP request.
Authentication alone is not enough though, someone could always be listening on the wire and capture the authentication cookie, and thus get hold of the session - "become you". The only solution here is to encrypt the connection on a lower OSI layer level (using SSL/TLS). This is why you should always use SSL when it comes to authentication.
This Ruby on Rails security guide has a great explanation on how to deal with AJAX requests that could be potentially exploited. It's not specific to RoR so the concepts can apply to any platform.
One way to reduce the risk of cross site requests is to use POST for actions that modify or delete data.