I am new to this field. If I want to hide parts of my webpage, should I use client side scripts of server side codes (or both)?
Because one of the teachers told me that you can't only rely on Javascript, because people can prevent Javascript by using "Do not allow any site to run Javascript".
If the data is sent to the client, the client will always have a way to see it. For example, JavaScript enabled or not, you can always open Chromes developer console and inspect the document, or pick view source from the main menu.
The only way to keep information from a client is to not send it to them in the first place. This has to be done server side.
Still, you should seriously consider asking yourself if you have anything truly worth hiding. For the most part, silly, inexplicable attempts to hide page source just leads to massive user inconvenience, like disabling context menus and such, and never actually works. Never understood why folks thought that was a good idea.
On the other hand, things like authentication and authorization, database interaction, etc. you would want or have to do server side.
As for generating actual content, just for presentation not for the purpose of "hiding" things, generally it's a mix of both, the balance just depends on the application. You'll have to make the call during design and development.
Related
I have a SignalR chat site that's meant for a school project (also uses C#). Theoretically, it is for trusted users, but as everyone will attest - never trust your users. This was proven to me as I sent out the link to a couple of my friends and they immediately tried to break it, ha ha.
I've sanitized all inputs properly now, but one thing that they were still able to do was to use the browser console tools to manually call the functions needed to send messages, etc..
Example: $.connection.chatHub.server.sendMessageToAll('FakeUser','FakeMsg',0);
I would like to prevent these types of actions. I recall a while back Facebook actually disabled the console window for "security" purposes. I even found several{1} resources{2}, which detail how this was done and attempts to further prevent console use once Chrome had fixed this.
However, none of these options work anymore and because browsers are constantly in flux, I'd rather not attempt to block at this level.
I was wondering if anyone on Stack knows of a better way to prevent these types of attacks? Is there a good way to check where the call is coming from? Does SignalR have a good method to prevent this? Ideas/Discussion would be surely welcome.
Trying to lock down the client like that might work reasonably well to prevent non-technical users from messing with your app, but it will do next to nothing against a knowledgeable and resourceful opponent. The circumstances under which such security measures make sense are rather limited, and certainly do not include any application that is accessible to everyone from the internet.
The only safe approach is well-known and very simple: the server does not trust the client for anything. It doesn't then matter what the client attempts to do as the server will refuse all actions it does not deem valid.
In your example, the server would assign a randomized opaque connection id to each session. The client would only be able to convince the server to do anything if they sent a valid id as part of their request; then, the server would not need to trust the client for a username because it would already know what connection each user has logged in from and could produce the username when given the id.
I am building a website which uses a lot of javascripts. I want to know if a user can edit the js too along with seeing it.
For example, I have an ajax function which calls a.php. Can user just edit the js function in firebug or something similar to make it b.php which I want don't want to be available to everybody.
Similarly, I call an ajax function with parameter x. Is it possible for a user to make that parameter y and then call that function.
Yes. Anything in the user's browser is under the control of the user.
You have control over nothing beyond the edge of your HTTP server.
Anything that is front end, that means, HTML, CSS javascript in any of its forms or any other scripting client side languages can be modified and it is your job as a web developer to expect them to be modified by curiosity of the user or just to try and find vulnerabilities.
That is why while having client side validations (javascript in any form or just HTML5 ones), it is also of utter importance that you actually validate this stuff on server side, with whatever language you are using (PHP, Ruby, ASP just to give a few examples).
On Chrome, users can easily press F12 on their keyboard to see your javascript/html/css code and try to modify it, we as web designers/developers do it as well for just inspiration, check out how something works, and well expect other people with different intentions to do it.
Same goes with Firefox, opera and pretty much any other web explorer.
Your job is not to prevent this, but to prevent that when someone changes something on the client side, the server side is ready to respond back in an appropriate way, preventing harm to the information on your servers.
To give a concrete example, that is why people take so much time in making sure queries to databases are sanitized, and not subjected to sql injections. More information about those here: http://www.unixwiz.net/techtips/sql-injection.html
So no, you can't prevent users from modifying your front end files, at most you can try some practices I've seen around like disabling right click (really annoying).
I've been attempting to do some research on this topic for a while, and even cite the following Stack Overflow threads :
Javascript Hijacking - When and How Much Should I Worry
JSON Security Best Practices
But my basic problem is this.
When I am building my web applications, I use tools like Fiddler, Chrome Developer Tools, Firebug, etc. I change things on the fly to test things. I can even seem to use fiddler to change the data that gets sent to the server.
What stops someone else from just opening up my webpage and doing this too? All of the jQuery validation in the world is useless if a user can just hit F12 and open up Chrome Developer tools, and change the data being sent over the wire, right?
I'm still relatively new in this field and this just has me very concerned as I see "Open" Protocols become more and more ubiquitous. I don't understand SSL yet (which is on my list of things to begin researching), so perhaps that is the answer and I just haven't dug deep enough. But the level of flexibility I have over manipulating my pages seems very extreme - which has me very concerned about what someone malicious could do.
Your concerns are indeed justified. This is why you should always validate everything on the server. Client-side validation should only be used for UX.
JavaScript's security is, in a nutshell, based around a trusted server. If you always trust what code the server sends you, it should be safe. It's impossible for a third party (like an ad supplier) to fetch data from the domain it's included on.
If the server also sends you user generated content, and in particular user generated code, then you have a potential security problem. This is what XSS attacks focus on (running a malicious script in a trusted environment).
Client side validation should focus on easy of use, make it easy to correct mistakes or guide the user so no mistakes are made. The server should always do validation, but validation of a more strict nature.
Validation should always happen Server Side, Client Side Validation is only valuable to make for a more convenient experience for the user. You can never trust a user to not manipulate the data on their end. (Javascript is ClientSide)
Next if you are wanting to secure your service so that only user1 can edit user1's profile you'll need to sign you JSON request with OAuth (or similar protocol).
yeah nothing can stop anybody from interfering the data that is being sent from the browser to your server and that's the reason you shouldn't trust it
always check the data from the user for authenticity and validity
also with it you can check and interfere with the data that big sites like google and microsoft send back and you might get an idea.
You have to assume that the client is malicious-- using SSL does not prevent this at all. All data validation and authorization checking needs to be done server side.
Javascript isn't going to be you only line of defense against hackers, in fact it shouldn't be used for security at all. Client side code can be used to verify form input so that users trying to use the page can have faster response times, and the page runs nice. Anyone who is trying to hack your page isn't going to care if your page works or not. No matter what, everything coming into your server should be verified and never assumed as safe.
In a previous question I asked about weaknesses in my own security layer concept... It relies on JavaScript cryptography functions and thanks to the answers now the striking point is clear that everything that is done in Javascript can be manipulated and can not be trusted...
The problem now is - I still need to use those, even if I rely on SSL for transmission...
So I want to ask - is there a way that the server can check that the site is using the "correct" javascript from the server?
Anything that comes to my mind (like hashing etc.) can be obviously faked... and the server doesn't seem to have any possibility to know whats going on at the clients side after it sent it some data, expept by HTTP headers (-> cookie exchange and stuff)
It is completely impossible for the server to verify this.
All interactions between the Javascript and the server come directly from the Javascript.
Therefore, malicious Javascript can do anything your benign Javascript can do.
By using SSL, you can make it difficult or impossible for malicious Javascript to enter your page in the first place (as long as you trust the browser and its addons), but once it gets a foothold in your page, you're hosed.
Basically, if the attacker has physical (or scriptual) access to the browser, you can no longer trust anything.
This problem doesn't really have anything to do with javascript. It's simply not possible for any server application (web or otherwise) to ensure that processing on a client machine was performed by known/trusted code. The use of javascript in web applications makes tampering relatively trivial, but you would have exactly the same problem if you were distributing compiled code.
Everything a server receives from a client is data, and there is no way to ensure that it is your expected client code that is sending that data. Any part of the data that you might use to identify your expected client can be created just as easily by a substitute client.
If you're concern is substitution of the client code via a man-in-the-middle attack, loading the javascript over https is pretty much your best bet. However, there is nothing that will protect you against direct substitution of the client code on the client machine itself.
Never assume that clients are using the client software you wrote. It's an impossible problem and any solutions you devise will only slow and not prevent attacks.
You may be able to authenticate users but you will never be able to reliably authenticate what software they are using. A corollary to this is to never trust data that clients provide. Some attacks, for example Cross-Site Request Forgery (CSRF), require us to not even trust that the authenticated user even meant to provide the data.
I don't know a lot about security, but I'm trying to figure out how to keep my site as safe as possible. I understand that as much stuff that I can handle on the backend the better, but for instances where I'd like to hold some variables on the client, is that stuff utterly unchangeable?
For instance, if I set a global variable to the user's role (this is a pure AJAX web app so a global variable is always available), is it possible by any software to edit javascript within the browser so that a user might change their role?
Security is a big topic in the web development world and it is important for you to determine how secure your web application should be.
There are 3 parts for you to notice
Frontend (the website)
everything here is insecure, whatever shown on you in the browser could be changed or modified. Just go to the debug console and you could change the variable and rerender the html page again
Transportation level (https)
web communication is based on the http(s) protocol that allows you to communicate between your server and client. Using https will prevent you from man in the middle attack
Backend
always make sure to authenticate and check the data sent from your client (POST, PUT, DELETE)
Prevention
The good thing is even you change the variable of the client side, it only appears on that client session and doesn't effect any others. There are few ways you could increase your security in your frontend
Obfuscate
this means make your source code harder to read. You could try to use tool like minification, and concatatenata your source code.
Data
Never ever store user sensitive data (password, user info) in the client side, since people could just change and see it
This should get you learning more about security
With developer tools if you run in debug mode with breakpoints then you can change values of variables.
All data that goes to the client can be viewed and tampered. There are alot of ways to do that (Developer Tools, HTTP Proxy, ...).