If HTML, CSS, and JavaScript are processed by the user's computer, why can't JavaScript send commands to the OS level? I know if this happened, hackers could exploit a lot of computers but what prevents it from happening?
Simple answer : its the browser, you see browser is like any other program on your computer given enough permissions it can do whatever it wants to through system calls.It can access your hard drive (and not just simple filesystem i mean block/sector level access) reading/deleting whatever it wishes it can even read/edit your MBR!.Other fun stuff like ejecting CD tray/ put os to shutdown or sleep/ formatting your drives xD / infinite nag screens/ disabling network adapters/ and other crazy cool stuff you can imagine all can be done if browser makers wish to expose those functionality through javascript, for eg. if microsoft in some distant future were to expose some system API through system object much analogous to the window object in current javascript spec. .You write a script like this one <script>system.ejectDrive['cd']</script> , browser may translate in into actuall winapi call mciSendCommand(mPar.wDeviceID, MCI_SET, MCI_SET_DOOR_OPEN, 0); and bingo ! its cool but what if a hacked ebay server sent you code for wiping your D:\ drive clean?.Now you can imagine why browser makers take security so seriously.You might wonder why i'm so obsessed with disk drive ejection xD, actually i chose this example due to its physical nature . A random bit changed in his computer's memory may mean nothing to an average user unless it has some sort of " physical effect " even though that effect might be dependent on that bit somehow.
JavaScript can have access to your computer in some cases:
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/
Some ransomwares have their js files as e-mail attachments and tempt users to open it locally.
It is not about JavaScript, it is about the software that runs the script, and how the software interprets it.
With js in browser, it can only do what the browser allows it to.
With Node.JS, you can write "JavaScript" to start your own server.
When run locally in Windows via a double click, it can be very dangerous.
Related
I want to identify a user by unique machine id across all browsers. So came up with an idea of launching a app which determines the machine-id (like electron using nodejs) and passes back the info to the browser that launched it and use for identifying the user.
I have seen something like this been done on canyourunit
Can anyone point me right direction where can i find some info about this kind of approach.
As you would be asking a user to download and execute native code, electron or whatever else, there are several complicated issues to consider.
The obvious first one is that you must consider the user platform (OSX, Windows, Linux...) then, communicating back with the browser directly (which one?) is probably not practical.
Your native application could however send the machine id/fingerprint to your backend so you could identify what web client is what.
This is quite involved, fragile, and even if you only support Windows, will fail in many scenarios (system policies, firewalls, antivirus, proxies, strange network setups...)
All in all, it would seem that you should consider more standard Device fingerprinting techniques if you only need an ID.
I don't have a lot of hope for this one, but I have to ask. I am hoping, for didactic purposes, to come up with some means by which a student could load a simple javascript program into a browser, and have it interact with them in the old-fashioned command line manner, where it prints a line and then reads a line of input. This works fine if you use prompt(), but the fact that it creates popups is aesthetically annoying, and today's browsers cheerfully volunteer to stifle the scripts which overuse it. The problem is, prompt() appears to be the only way browser Javascript has of actually pausing a script to wait for input. If we avoid it, that throws us immediately into having to deal with a real-time GUI event input model.
I've been looking for a way to fake it -- to set up some kind of environment in which it is possible for a Javascript method to wait for input and then return when it's given. The best possibility I've got so far is to connect it to a Java applet, but the java applet brand is kind of poisoned now and I doubt people would want to install the plugin. Could there be another way? Worker threads? A browser add-on? Some server-side trick? Does anyone have an idea?
This question is now years old... I wonder if the addition of promises and async/await to Javascript makes this any more possible now?
...I sort of got it to work. If the read-eval-print loop is in an async function and uses await for the line that reads input, you can indeed make an old fashioned linear read-eval-print loop in an event-driven browser environment. But I don't think you can make the main thread wait on input without an async function, except with the grandfathered prompt method (which they're now getting ready to deprecate).
The technical term for what you want is a REPL: a Read-Evaluate-Print-Loop. There are many REPLs out there.
The Best Browser-Based Solution
Use Google Chrome's inbuilt console! It's a Javascript REPL that can also let you interact with a web page. You can access it by using Ctrl+Shift+I on Windows and Unix inside Chrome, or the equivalent command on a Mac (Google it!).
To load a file and play with it, all your students need to do is create a directory structure like this:
project
|--> index.html
|--> javascript.js
make sure index.html has a script tag that points to javascript.js, and then open index.html with Chrome. Voila! You have loaded a Javascript file, and can now play around with it in Chrome.
It's the best solution because you get the full power of the DOM, can do REPL stuff, and is virtually painless - everyone uses Chrome, and your students can even go home and mess around with it completely.
A Browser-Based Alternative
Rather than reinvent the wheel, you can also use Repl.it.
It's a browser-based Javascript REPL website that supports inserting an arbitrary Javascript program, and interacting with its contents. This is the closest you'll probably get to meeting your requirements - it'll be unable to interact with the DOM (obviously), but it'll more than work.
Non-Browser-Based Alternative
If the requirement for a web-based solution can be relaxed, simply using Node.js' inbuilt REPL on a terminal can be more than sufficient.
You could install Node on your lab's computers, and have people play with Javascript in that capacity. There'll be no DOM, but you could certainly have them write functions and algorithms to solve simple problems. Plus, it'd be a good way to introduce them to the fact that Javascript is no longer client-side-bound.
The fact that you'll be interacting with Javascript in an actual terminal, rather than an emulated one in the browser, is another neat bonus.
If I've Misunderstood...
Some of the question comments make it sound like you want a way to be able to interact with terminal utilities using Javascript from a browser. If that is the case, this is impossible.
There is no way for Javascript to evaluate, parse or do anything on the command line that isn't written using Javascript. You cannot expect the equivalent of a bash ls using a browser-based solution - that's because browsers don't have access to your underlying filesystem, which is a good thing. You cannot run sed, awk, grep, etc. for the same reason - Unix utilities are inaccessible to a browser. There are ways to run Unix utilities using Node, of course, but then you will be teaching them how to use Node, rather than how to play with the Unix console.
If all you want, however, is a way to SSH from a browser into a common environment, there are certainly browser-based ways to do that. FireSSH is a Firefox plugin (now also ported to Chrome) that lets people SSH into a common server. They can then do ls, vim, etc. and have it run in the server, with the results piped back to their browser screen. You'll have to think carefully about security in this case, of course, but I think simply giving people user permissions for this server should more than suffice.
Note that FireSSH doesn't use Javascript to parse or do anything - all it is doing is relaying commands you type to a server, having the server execute those commands remotely, and then piping the results back to your screen.
Alternatives to Prompt
I added this after understanding OP's requirements in more detail.
This is a question that has been asked before. I am fond of library solutions, and in 2013, iocream.js was developed for just this sort of browser functionality. You can embed it in a page, and use the jin function to assign values.
If going with a Node.js solution, by far the best approach is to make use of the prompt library. I personally find it very useful for embedding within Node.js applications.
SpiderMonkey is Mozilla's C++-based Javascript engine, and supports a function called readline(). Unfortunately, there doesn't appear to be a mainstream browser implementation.
I am completely new to javascript programming and I have a question that I didn't manage to find an answer for anywhere.
I have recently put together a simple slideshow to view the photos remotely that I host on my home computer. This by itself works fine. The problem I run into is that when I'm viewing photos I don't interact with the hardware, which after some time causes the monitor to switch off. This is particularly annoying when watching photos on my mobile phone.
My question is: is there a way to prevent this from happening? I am thinking in the direction of faking a mouse or other event every time I refresh the photo, but I have no clue how to do that and if it is possible.
Any help is greatly appreciated!
No. JavaScript on the browser cannot interact with the underlying system. Simulating keystrokes in the browser will not stop the screen saver from turning on. This is for security reasons, so that malicious code can't harm the system when you visit a web page.
Link on JavaScript Security
The modern JavaScript security model
is based upon Java. In theory,
downloaded scripts are run by default
in a restricted “sandbox” environment
that isolates them from the rest of
the operating system. Scripts are
permitted access only to data in the
current document or closely related
documents (generally those from the
same site as the current document). No
access is granted to the local file
system, the memory space of other
running programs, or the operating
system’s networking layer. Containment
of this kind is designed to prevent
malfunctioning or malicious scripts
from wreaking havoc in the user’s
environment. The reality of the
situation, however, is that often
scripts are not contained as neatly as
one would hope. There are numerous
ways that a script can exercise power
beyond what you might expect, both by
design and by accident.
Over the decade since this questions question was originally asked JavaScript has grown to provide much of the OS functionality (usually in a secure manner). The "wake lock" functionality is slowly being implemented. Currently there is a draft for the navigator.getWakeLock interface: https://www.w3.org/TR/wake-lock/#conformance
Chrome (https://developers.google.com/web/updates/2018/12/wakelock) and Mozilla (https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API) are considering it in various manners.
No, JavaScript cannot affect hardware or operating system. Just turn off monitor power saving settings until you're done with the slideshow.
Yes, It's possible now :)
Just use NoSleep.js library: https://github.com/richtr/NoSleep.js
It's working form me with Reveal.js slides on my Android Tablet
You could do it with a console application written in c# that interacted with the os
since js is a client side browser language it can only interact with the browser/bowser
I am currently creating a web application that will be deployed in an intranet environment. I chose firefox to be the browser that will run it.
However, in the application I am building, I need to be able to print to different printers quickly since they use different paper size depending on what client is coming. To avoid many time-wasting mistakes that could occur, for instance someone choosing the wrong printer and wasting paper. Also, the time used to find the right printer for the job and then pressing print is considered too long in the current context.
Is there any solution to this problem? I understand the potential security flaw behind this, but please be aware that this is solely an intranet project and that I can reduce the browser's security to the lowest since they don't access internet.
I know there could be something doable behind IE (ActiveX or VBScript) but I am using firefox. Also, I guess there could also be something rather tricky that when you press print on the browser, it saves what needs to be printed to a DB and then there is an exe app that runs and fetch that DB every set ammount of time and print to the right printer.
Any suggestion would be greatly appreciated. I doubt I am the only one to ever face this issue! :)
Thank you very much.
You need to write a Firefox extension or plugin and distribute it throughout your enterprise.
There's an alternative approach, that might even be faster, besides requiring even less setup and development.
If you are in an intranet, why not print from the server instead of the browser?
You'd have the following advantages:
Zero setup on the client side (except perhaps choosing a "printer set" according to the location)
Zero dependency on the browser setup, version, page configuration, etc
More flexibility (depending on the libraries you use to print, you can do things that a browser does not allow)
Of course the downside might be additional development on the server side, but that's probably easier.
I've been thinking about the access web-based applications have to an OS.
I'm curious:
What is the best way of determining
this as it currently stands?
Is the trend leaning toward more, or
less access?
What functionalities should be
open/closed?
A simple example would be.. say your g-mail alerted you in the task-bar when an incoming e-mail is received.
In the past, browsers have shown a strong tendency to prevent all manner of access to the operating system (and also the browser chrome). The fundamental risk is about trust and deception; if all you have done is visited a website, do you want it popping up dialog boxes or reading files on your hard drive? Even worse, you might not have visited the website on purpose; you might have been subject to a phishing attack where a spammy email linked you to a URL that looks like a popular site, but has a "1" instead of an "I".
It's nuanced to say which way the trend is going. In one sense, you can now do more than before, because you have the browsers enabling GPU support and, as part of HTML5, offline storage. All of this is being done with careful consideration of the security issues though, ensuring sandboxing takes place. On the other hand, you have browsers locking down on things like cookies on the file:// URI.
Many apps are increasingly web apps, but it's not as simple as just pointing to the web app in your browser. It might be an app you installed as a mobile web widget, or purchased in an app store like the Palm Pre's, where most apps are basically just web apps. The point is, the trust scenario is different in each case; I'd feel more confident giving certain OS access to an app from a reputable app store, where the code has been inspected, the producer has signed it, and the app's actions and privileges can be tracked ... than a random website I happened upon.
Any access that is given is going to be abused by malware. Guaranteed.
I think the trend is toward less access; consider Google's Chrome OS, in which you do all of your work within web applications, which have no native access to your system at all.