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
Related
I'm developing an HTML5 game using javascript and canvas, and I wonder how to protect it from the firefox scratchpad or any other script injection tools like it.
If any user can run its own code in mine, I really don't see how to prevent him from calling the onWin() method or modify its score to 1 billion and so on.
That's such a huge security breach that I'm now thinking about re-code it in flash or java.
What do you think ?
Regards.
Here is what you need to do:
At server side you need to check only authorized user is able to
update any data in server.
So if any update request is coming to server from client before updating you need to make sure the client is authorized to do so.
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 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)
I'm thinking about creating an RIA version of a traditional web application. In a traditional web app, most of the code is on the server, obviously, out of touch of the client. There I would have, at very least, conditional code to check if the current user has permissions to do something, or what form fields to display.
In a RIA, all code is running in the browser. So I have, it seems, two choices.
If I need to display a form, grab it dynamically from the server. This works, but it makes the server do more work than just marshal back and forth JSON.
Bring back the account data from the server, and do all authorization code on the client. I took a quick peak at basecampmobile, and seems they are doing something like this.
My question is, does hiding this information behind a closure really protect it, or is this "security by obscurity"?
I would do authorization on the server and the client. The client authenticate with the server and the server returns only data belonging to that client/user nothing else. Then on the client you check the authorization on specifics to update the UI accordingly.
Remember you can always jump into the dev tools and see the network traffic so we are not even talking about obscurity here...
When you work on a thick client, you should check for user security both on the server and client because client can be hacked easily.
I don't like RIA services role based authorization. It feels much more intuitive to use access based authorization like what SQL Server has, and it doesnt force you to re-implement the security at client side. For example instead of saying x, y, and y can access this createCustomer(..) method, it is more intuitive to say someone with the "Create" right can access this method.
I have an open source framework that faciliates this type of authorization read more here. It is called saf-framework.
I apologize that there is a similar question already but I'd like to ask it more broadly.
Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?
Or, is there any way at all to load an mp3 audio resource in flash which fails invisibly in the case of a 401 status code rather than letting the browser show an ugly dialog?
The Adobe Air run-time will suppress the authentication if I set the "authenticate" property of the URLRequest object but this property is not in the Flash run-time. Any solution which works on the client will do. An XMLHttpRequest is not likely to work as the resources in questions will be at different domains.
It is important to fail invisibly because the application will have a list of many audio resources to try and it makes no sense to bother the user to try and authenticate for one when there are many others available. It is important that the solution work on the client because the mp3's in question come from various servers outside my control.
I'm having the same problem with the twitter api - any protected user requires the client to authenticate.
The only solution that I could come up with was to load the pages serverside and return a list of the urls with their http response code.
"Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?"
No, not in general. The 401 response is the only standard way for the server to indicate that authentication is necessary.
Just wrap your access to the resource that might potentially require authentication to an Ajax call. You can catch the response code, and use javascript to do whatever you want (ie. play that sound). If the response code is however alright, then use javascript to forward user to the resource.
Most likely this approach will generate slightly more load on server (you might have to resort to loading the same resource several times in some circumstances), but it should work. Any good tutorial about how to use XMLHttpRequest should contain all you need. Take a look at for instance http://www.xul.fr/en-xml-ajax.html
If you are using URLRequest to get the files, then you are running across more than just elegant error handling, you are running into a fundamental difference in the Flash and AIR run-times.
If using the URLRequest object to retrieve files you are going to get a security error from Flash on every request to every server that has not set a policy file to allow these sort of requests. AIR allows these requests since it basically IS the client. This makes sense since it's the difference between installing an application and visiting a web page.
I hate to provide the non-answer, but if you can't make a server-side call, and you are hitting a range of "not-known" servers, it's going to be a tough road to hoe.
But maybe I misunderstand, are you just trying to Link to the files and prevent the user from getting bad links, or are you trying to actually load the files?