I have an asp.net website with client javascript making lots of ajax calls back to the server. Is there any way I can prevent a google chrome extension from calling my ajax endpoints or to detect when they are being made by the chrome extension code and not my own javascript code. So far I have tested using the referer, httponly cookies, but there is no difference between the 2 calls. Any ideas would be appreciated.
No, there is not.
Chrome extensions have elevated permissions. They 'out-permit' your website JavaScript code and may manipulate and call it.
Even if you add something like an anti CSRF token, an extension could still read it and bypass that protection. They can run JavaScript code on your site and make modifications to your own code on the site on the fly without notifying your or your users.
The only thing you can do is not trust the client with anything critical, treat all requests you receive as hostile and require clients to authenticate before making requests to your server.
(I'm assuming you mean a chrome extension running on your site)
Related
I have been trying for sometime figure out how the js at yt login page works to send the appropriate form data with requests python to log in a youtube account but I still could not after multiple tries to read the code, any suggestions?
Modern web site logins are increasingly dependent on Javascript, cookies, and multiple page requests. They're rarely a matter of simply sending form data, and the methods change with time. Without running the Javascript code, it can be tricky to make this work and keep it working.
For scripting Youtube access with Python, I recommend using Chrome in the headless mode (--headless option). If you start it with the Remote Debugging Protocol, it's easy to send commands to the browser from Python.
I used the following project as the basis for the login authentication logic for an app: https://github.com/cornflourblue/angular-authentication-example
When the backend was down, I manually altered the frontend to avoid the validation of user credentials to workaround the $http calls.
That made me wonder if it is possible to use Chrome DevTools or Firefox's Dev Tools to circumvent the $http call and make the app think the credentials were accepted.
So far on my own, it seems Chrome still runs the original files and any altered files on stored elsewhere and not used. But I couldn't reproduce the hack just within Chrome DevTools, but I'm not an expert and was curious if it was possible.
Yes it is possible to alter client side scripts and hack any javascript code...
That is why there is a log in process the purpose of which should be assigning valid session credentials for the client side to provide to the server with each request so that it can be validated and acted upon accordingly.
Basically, your application must make sure that no sensitive information is exchanged before the valid session is established making any client side code circumvention obsolete
If I'm loading arbitrary external javascript code in a browser setting, is it possible to ensure it can't make the browser run make any ajax calls or network requests?
Can you prevent any resource calls? - No. (haven't explored the 'extension' route though)
Since even an <img src='any valid url'> creates a resource request which your code cannot prevent.
Can you prevent ajax calls? - Yes, to an extent.
Assuming that you want to ensure that any third party libraries shouldn't make any arbitrary ajax calls (cross domain), you will simply ensure that you don't enable CORS in your web server.
Your own application code can make ajax calls since they are in your domain only. However, you can filter those calls on server to check for specific properties like purpose, credentials, etc
It may be worth exploring google caja (haven't tried that myself)
Note - It is not a duplicate of that question. The concerns are different. I don't want to disable that firebug let it be open let the user to use all functionality provided by firebug, I only want firebug not to show service calls.
I may be wrong but I want to ask when browser developer tools like firebug displays service calls and their request response Is it not a security threat? If not why so?
IF it is, Is there any way by which we can hide the display of service calls after build deployment in firebug or developer tools?
You can see a get request shown by firebug in Mozilla firefox.
I have searched for this but not getting anything fruitful and I am also not able to find any post related to this concern on stackoverflow. If any one has any information please share it.
No, this is not a security issue on any properly designed web site / service. The browser, and requests performed by the browser, should all be considered to be under the user's control. (Indeed, from a security perspective, the browser should be considered an extension of the user, rather than something separate from them.) As such, the user viewing something that's under the user's control is not a risk at all.
If your web site is sending data that the user shouldn't be allowed to see in HTTP(S) requests, you've done something wrong. That data should never leave the server at all if it's that sensitive - move the logic that needs it off of the client (e.g, Javascript) and back onto the server side.
If your web application follows security through obscurity then it would be harmful.
But as long as you make your web application secure with common vulnerabilities like CSRF, XSS taken care of then anyone seeing the request made / response received doesn't matter.
I have a nodejs app that runs a web server and works as a web API. Simple GETs to interact with it. My goal is to be as accessible as possible by any language or programmatic scenario. My biggest problem is that javascript run in the browser can't hit it because the browser (specifically chrome) prevent cross site scripting. I'm open to any ideas that allow this. I want any site to be able to make requests against the url, sort of like how twitter has a javascript API.
I've tried using jQuery's ajax with JSONP but I was having all sorts of problems. Either it wouldn't go through or if it did go through I wouldn't get the response.
If there's a pure javascript way, I'd prefer that because of it having fewer dependencies.