I want some content of my website to be dynamically loaded after login. A $.post(...) interacts with a servlet which validates the user's credentials, and then a $.load(url) loads the content from a separate page into a <div>. I noticed that, as long as I know where to fetch the content from, I can force this behavior from the chrome javascript console, bypassing validation.
How can I prevent a user from doing this?
You can't.
Once a document has been delivered to the user's browser it is completely under the control of the user. They can run any JS they like.
The URLs you present on your webserver are the public interface to it. Anyone can request them. You can use authentication/authorization to limit who gets a response, but you can't make that response conditional on the user running specific JavaScript that you supply.
The server needs to authorize the user each time it delivers restricted data. You can't do it once and then trust the browser to enforce it.
You can add a secret parameter to the url you load. By defining a random variable in the users session (server side) or in the database, and then return this variable once the validation is successful so your javascript code can use the variable in the next load call. In the load url you can check at the server side if the secret parameter had the correct value or not.
Hope its clear.
The simple answer is: You Can't.
JavaScript runs within the browser and therefore a user or application can run their own code whenever the feel like. This could be as simple as adding new CSS or running their own JS codes.
The main thing you can do to disable this is to ensure all of the requests are validated on your server side before being run as well as allowing only entry for certain types of information (like only allowing integers as numbers to stop strings coming through).
Something close to this sort of problem is XSS or Cross-Site Scripting. A 3rd party will try to inject some malicious code to a trusted website, usually some form of POST, to affect different users. Here is some more information on the matter
Cross-Site Scripting - Wikipedia
CSS - OWASP
Related
I have a website builder which allows users to drag and drop HTML blocks (img, div, etc...) into the page. They can save it. Once they save it, they can view the page.
I also allow custom code like JavaScript. Would it be safe to have their page be displayed on another server on a subdomain (mypage.example.com) but still fetched from the same database as the main server, or does it not matter to put it on the same server as the main server?
As far as I know, they cannot execute any PHP code since I will be using echo to display the page content.
Thanks for help!
That depends on your setup. If you allow them to run custom JavaScript, they can probably steal session tokens from other users, which could be used to steal other accounts. I would recommend reading about XSS (Cross-Site-Scripting).
In short: XSS is the vulnerability to inject code into a site, which will run on other peoples computers.
It wouldn't make sense to give you a strict tutorial on how to do this at this point, because every system is different and needs different configuration to be attack-resistant.
Letting users put code somewhere is always a risk!
there is no need for another server, but you do need another domain to prevent Cross Site Scripting attaks on your main page. and no, a subdomain may not be sufficient, put it on another domain altogether to be on the safe side. (luckily domains can be acquired for free if you're ok with a .tk domain)
Would it be safe to have their page be displayed on another server on a subdomain
even a subdomain could be dangerous, just put it on another domain altogether, and you'll be safe.
or does it not matter to put it on the same server as the main server?
you can have it on the same server. btw, did you know that with shared webhosting services (like GoDaddy, hostgator, etc) there's thousands of websites sharing a single physical server?
also, DO NOT listen to the people saying you need to sanitize or filter the HTML, that is NOT true. there is no need to filter out anything, in my opinion, that is corruption of data. don't do that to your users, there's no need to do it. (at least i can't think of any)
As far as I know, they cannot execute any PHP code since I will be using echo to display the page content.
correct. if you were doing include("file"); or eval($code); then they could execute server-sided code, but as long as you're just doing echo $code;, they won't be able to execute server-side code, that's not a security issue.
I am building my first node.js webapp. I don't need to manage users registrations. I just need an admin page wich easly allow updating the content of some pages.
I have almost finished the development phase but there is something about security I would like to clarify.
ADMIN PAGE: there are 2 level of security:
1) The admin page is linked to mywebsite.com/hexadecimal_string .
Maybe it's very stupid but the admin page is a "secret" page. Linking
it to mywebsite.com/admin is too much common. Do you think that using
an hexadecimal string can be considered a first level of security?
2) Of course there is a password for admin, stored in my database. If
the password is right, a temp cookie is setted. Maybe I should
encrtypt this password while is posted but I'm not planning to use
https. Is there a way, different by using https, to make the posting
of the password more secure ?
CORS: I don't need CORS but there is a thing that is making me crazy:
In the homepage everyone can post some data to server (we are talking about newsletter emails and others personal datas)
suppose someone reads the javascript code of the home page(in particular the ajax urls) in same way and he tries to post data to the same urls but using a personal script that skip the validation phase. Of course I did the validation to server also but I'd like to not accept any req coming from personal scripts written by other than me. The server should respond only to requests coming from my javascripts, tha anyone can run accessing to www.mywebsite.com. All other requests coming from different scripts will recieve 500-server error.
Now, I read about lot's of people that is tryng to ALLOW CORS. So I was supposing that cors is disabled by default but I tried to post data from another website to mine and the data have been sent without problem and the server responds 200. Why? Can I manage this thing?
There are other common things that I need to analyze and manage for security in my situation??
Since you don't want to use https and are looking for an alternative to that I presume you don't want the password to be sniffed in transit. I suggest a simple encryption decryption algorithm might work out for you. For the second issue, you can add a validation string which the client JS will pass along with other parameters while hitting your server API's. If you generate this string each time the client loads some specific page, then duplication of string will also be tackled.
In case you don't want at all to maintain any sort of db on server side, then attach a hidden HTML field to the API hits. This hidden field again you can encrypt and sent. If you broadcast this field periodically from the server, replication of the field will not be possible.
Also in CORS, you cannot request for data from a cross domain. CORS block comes in place when the browser gets a reply back from the server. Only posting of data does not cause any issue.
I recently found an exploit in my router to basically give me root access. The catch? There is a nonce hidden form value that is randomly generated and must be sent in for it to work that makes it difficult to do "easily"
So basically I'm wanting to do something like this in javascript:
get http://192.168.1.254/blah
use a regex or similar to extract the nonce value
put the nonce value into a hidden field in the current page
submit the form by POST to http://192.168.1.254/blah complete with the nonce value and other form values I want to send in.
Is this at all possible using only HTML and Javascript? I'm open to things like "must save HTML file locally and then open", which I'm thinking is one way around the cross domain policy.
But anyway, is this at all possible? I'm hoping for this to be able to run from at least Firefox and Chrome. The audience for this is those with some technical know how.
EDIT: I've rewritten this since my original answer was not correct.
Since you can make an AJAX call to a local file, here is what you do.
"The AJAX page" is the page making the request.
"The requested page" is self explanatory.
You have your AJAX page on your computer. The AJAX pages calls the requested page from your computer, in the same folder as itself.
You instruct the user to fetch the requested page from their router and put it in the same folder as the AJAX page.
The cross-domain policy now no longer applies, since both files are in the same folder.
Your page can have a POST form where the action (target page) is cross-domain and there should be no restrictions.
If you can run PHP code on your page, try using cURL. This can make cross-domain requests.
This cannot be done from a regular HTML page. The Same-Origin policy will prevent you from connecting to the router. (Saving the page locally won't help; browsers started heavily restricting what a local page can do several years ago.)
If you're really bent on making this happen from a browser, you could write an extension. Origin restrictions do not apply to browser extensions.
I am using some global variables on a web application, built on Html/Javascript. I am using these variables across pages (or portions of them), and sometimes they are used as post data for ajax calls. My question is: how secure is this? surely i can set different values for these variables (using a console for example) and then, the calls that rely on this var are made. Imagine the user sets some Id that corresponds to something that he even doesn't have access to..
How should this be done?
Thanks in advance
There is nothing different about this from any web application, from a point of view of security.
Anything sent from the browser must be treated as untrusted by the server. This includes URL parameters, form post data, cookies, http headers and anything controlled by javascript. All these items can be manipulated by an attacker.
Essentially, it doesn't matter what the values are in the client, you only need to worry about them when they hit your server in the form of a new HTTP request (this includes XHR). Until that point, variables with bad values can't do any damage.
Ensure your server can correctly authenticate the current user and only allow them access to data and actions that they are authorised to perform. Ensure that all data received from the browser is checked to be correct (if known) or of the correct datatype and within expected limits, rejecting the data and aborting the action if it is not.
if you use jquery, you can use
$.data()
With this, you can associate the data with an element, thus a unauthorized user will not be able to access it
Javascript has runtime type identification (everything is a var like visual basic), its a loosely typed language.
Javascript has its own security model though
User cannot access files (r/write)
It cannot access or look at user location, files, open windows without demand etc
It is not possible to protect the source of your javascript file either or even pwd protecting it as this is better done server side.
Even encryption or decryption doesnt work because somehow you need to tell your users the key
Worse, JavaScript can self-modify at run-time - and often does. That means that the security threat may not be in the syntax or the code when it's delivered to the client, but it might appear once the script is executed.
There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well.
Currently I have developed a site which is used for handle financial transactions. I have seen that some of my customers have done JavaScript injection attacks and have done some transactions which are not possible. As a example I have checked his cash balance before he place the order. But some of them did change that by running the following javascript in the address bar. They have taken the varible name by looking in to page source.
javascript:void(document.accounts.cashBalence.value="10000000")
Since this is critical I want to fixed it quickly. So is there a way to prevent JavaScript injection attacks?
You can obfuscate or hash variable names and/or values. However,
Don't use JavaScript, do every logic in the server-side instead.
In the end it's not even a problem of Javascript. Your server talks to the outside world using HTTP. It sends data using HTTP and receives data using HTTP. Anybody can request data from it using HTTP and anybody can send data to it using HTTP.
Think about this again:
Anybody can send data to your server through the very simple protocol that is HTTP.
The HTML and Javascript you're sending to people's browsers is just a nice help, an interface, to allow them to easily send data to your server. They could do the same using the curl command on their command line or by telnet'ing into port 80 and talk really low-level to it.
If your server blindly obeys any and all commands sent to it without checking their validity, you have no security whatsoever. Security and validity checks belong on the server, not on the client side interface. Because HTML and Javascript aren't the only interface to your server, nor are they in any way protectable and hence trustworthy.
Javascript runs in the user's browser. You ultimately have no control over it and should not trust it. Any verification you do in the browser is merely for the user's convenience so they can be alerted of problems as early as possible.
The backend code that accepts the order should do the authoritative check of the user's balance.
No client-side scripting (including Javascript) is good for verification, It should all be done on the server-side.
It is too unreliable to trust it specially if it is for financial records!!
It should be used for a better "user experience". Form validation while typing or whatever but not this!
Have found that if you make it to where server only excepts out going data not incoming data it works best but that poses a problem, if you are using a website that takes user input on the connected client then your preaty much screwed I sugset a simple java script line that in a sence makes it to where before you can send any java script you have to enter a basic set of variables so in a sence just have a login page start with somthing like this
System.out.printin ("Welcome, Would you like to login to edit?")
Then { System.in = "Yes"}
To prevent Javascript injection, you should have a Validation Feature whenever you allow your user to enter something. Try to use libraries that determine Javascript scripts that are entered to the form.
Also when displaying user inputs, you should Escape Texts to display it as is and will not be evaluated by the browser.
Utilize your server, your should place your business logic to the server and not to the client whether using Javascript or not. All data sent to the client are just view and should not process any business logic.