While I was developing some web apps, to me it became optimal to use a web service to interact with the server, and the rest I was enjoying to do with client side (JQuery). but when I was testing my code, I encountered a huuge hole in it, and i don't know how to prevent it.
The problem is that I can easily inject javascript and run any functions including webmethods from firefox's firebug tool.Is it a something known, and what should be done to prevent it.
THank you
This is not a hole at all. The client can only run JavaScript code on the page that they have downloaded from you on their own computer. It has no affect on your site at all.
As for the ability for them to make requests via JavaScript -- well, they can make requests via the browser too. What's the difference? Just make sure that your server properly validates all requests -- it should treat any request as if it were as malicious as possible.
Related
I'm currently making an open source browser extension that will send requests to my site. This can easily be done with Ajax, a request will be sent to the page action.php.
My site will use PHP, well now the question is, how can I make sure action.php receives the request from the original extension? I mean griefers could easily send false information to the server, or a fork could be used and send incorrect data. I thought of generating a token of some sort, but anyone could recreate it I guess.
How can I prevent this situation?
I have some experience with this myself. I've been building an extension with a login and eventually came to the inevitability that security in an extension is inherently difficult.
The issue is that an extension is just a bundle of JS and HTML that anyone can inspect the values of. This means that anyone determined enough to dig through your code can potentially find out how to bypass anything you have built in.
The solution I eventually came to is that, the extension itself cannot hold any long-lasting secrets. A session with a timeout is the only safe thing to store. The actual login for my extension is done via a website over HTTPS.
If you are trying to do this without any such login, your only recourse is to make it as difficult as possible to determine what needs to be sent by using an algorithm that can generate server verifiable tokens, and then only publishing minified code to the webstore.
EDIT: Reread the question and noticed that you said you are doing this open source. Without some sort of authentication on the webserver via HTTPS, there is little you can do to stop those determined to bypass your protections because they will be on display in your public repository.
For sensitive endpoints like this, it would make sense do to the data processing server-side. The client would only have to query the server to process the data.
I want to execute a nodejs script from a html file.
I'm trying browserify but i'm getting many errors like "http.createServer is not a function".
Is there any alternatives to browserify?
No alternative to browserify is going to let you do things which are simply impossible in a browser environment … including starting an HTTP server.
You cannot execute node.js scripts on the client side.
Actually, that statement isn't entirely true. If a script contains only code that both the browser and node.js can run, or can somehow detect which environment it's running in and switch over to code friendly to that environment, then it will work. But a script is limited to the capabilities of the environment it's running in, so calls like http.createServer() will not function in the browser. It's not defined in the browser, and probably never will be. That's too dangerous from a security perspective.
What you can do is create a server-side API in node.js, and have the browser call it through AJAX. The script serving up your API will be running in node.js, so it can do anything that node.js can do. However, because that code isn't running in the browser, it won't be able to affect the browser, except by whatever it returns.
I suspect that you actually need two scripts -one on the server and one on the client- that communicate with each other. How you set up that communication is up to you, but if you're going to be starting servers in response to AJAX calls, then you're going to need to be very careful about security. Still, this is doable; apps like webmin are common.
Starting a server on browser won't be possible.
No sane browser would allow that as it can lead to drastic security loophole and attacks.
Is there a way to send data packets from an active Python script to a webpage currently running JavaScript?
The specific usage I'm looking for is to give the ability for the webpage, using JavaScript, to tell the Python script information about the current state of the webpage, then for the Python script to interpret that data and then send data back to the webpage, which the JavaScript then uses to decide which function to execute.
This is for a video game bot (legally), so it would need to happen in real time. I'm fairly proficient in Python and web requests, but I'm just getting into JavaScript, so hopefully a solution for this wouldn't be too complex in terms of Javascript.
EDIT: One way I was thinking to accomplish this would be to have Javascript write to a file that the Python script could also read and write to, but a quick google search says that JavaScript is very limited in terms of file I/O. Would there be a way to accomplish this?
For security reasons, javascript in a browser is usually restricted to only communicate with the site it was loaded from.
Given that, that's an AJAX call, a very standard thing to do.
You can make HTTP requests using the XMLHttpRequest API, which Jquery abstracts with $.ajax and $.get. You can also use the lower level Websockets network API:
https://developer.mozilla.org/en-US/docs/WebSockets
Note that the XMLHttpRequest API will only allow requests to the same server, OR requests that return an appropriate Access-Control-Allow-Origin header.
It sounds like the Javascript is only going to send information, not receive any. In that case, you're in luck. I'm guessing you are also running the Javascript and the Python on the same machine.
Run a Python webserver on the machine the browser is running on. Here's a simple example:
http://webpy.org/install
Once visiting http://127.0.0.1:8080/ in your browser gives the message Hello World!, you can start adding more addresses to your website, for example http://127.0.0.1:8080/report_data, http://127.0.0.1:8080/report_event etc.
Your Javascript can then make AJAX requests using jQuery.ajax or XMLHTTPRequest, to the address http://127.0.0.1:8080/report_data, and pass the information as GET parameters.
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.