I'm planning a project which is to be PCI compliant, but I am stuck on a particular vulnerability and I can't think of a way to protect against it.

The scenario is that there is a kiosk installed in a public location that is running an HTML/Javascript application. The physical computer is locked away, but users can access the touch-screen and keyboard.

The kiosk would be firewalled and only allowed to load content from certain domains or IPs, but I'm worried about a user injecting code directly into the page.

What I'm imagining is that a person accessing the kiosk could inject code into the page using document.write() that would record user input, and then return to the kiosk later to gather the input.

At this point it seems like the only protection against this is that the user probably can't open a web console using only the keyboard. Are there either a) any way to prevent additional scripts to be loaded after a certain point? or b) any way to ensure that a web console can't be opened in a browser? Or some other protection?

In other words, besides physically securing the computer, what do I need to do to secure a browser-based kiosk application when the kiosk has a keyboard?

And ideas or thoughts are appreciated!

  • Would it be fair to say that your question is Besides physically securing the computer, what do I need to do to secure a browser-based kiosk application when the kiosk has a keyboard? Commented Dec 4, 2015 at 3:59
  • You should maybe check out nwjs if you haven't already, it has a kiosk mode and is cross-platform. If you disable the toolbar you cannot enter the JS console. However Alt+F4 will exit the application on Windows and there is no way to actually disable the CTRL+ALT+DEL function without a modified kernel. Commented Dec 4, 2015 at 4:58
  • @NeilSmithline, yes, that's a good summary of my question! I have updated my description. Thanks! Commented Dec 4, 2015 at 23:31
  • @JonathanGray, thanks for the suggest, I will look at nwjs! Commented Dec 4, 2015 at 23:31
  • @ninapavlich Another suggestion, if you're using Windows, is to check out all of the group policy options. They will help you lock down the system further. There is also one that will allow you to customize the shell, which by default is explorer.exe... If you set the shell to open your kiosk application instead, and only that application, then your kiost application will start instead of the desktop and taskbar and ALT+TAB will cease to function. Also, there is a tool if I remember correctly, called "forever", which restarts an application on close. That could be useful too. Commented Dec 5, 2015 at 3:03

2 Answers 2


From a web app point of view the vulnerabilities you describe are the same for any website and can be mitigated in the same way. Check out the OWASP top ten and ASVS for industry standard ways of dealing with these problems.

Otherwise some particular techniques off the top of my head include:

  1. Scrubbing input
  2. Use content security policy headers
  3. Use a WAF
  4. Clear all data after the session has finished

PCI DSS has requirement 6 to cover the development of secure software, take a look at the PCI council website.

Also I would imagine that your kiosk would be considered a virtual terminal, so check out SAQ C-VT to make sure you're cover there.

  • Thanks for your guidance Richard! For the specific attack I am thinking about, I think Scrubbing Input will be the right approach. But I also appreciate the other points your included to look at -- very helpful! Commented Dec 8, 2015 at 21:56

You can prevent a console from being opened by using Chrome kiosk mode flags. If you need a way of debugging in this mode you can use Google Chrome remote debug. Kiosk mode will also prevent javascript from being executed via the address bar as the address bar doesn't exist. The only way an attacker could circumvent this is to close the kiosk window via alt f4 or ctrl alt dlt and open a regular browser(however a simple login should help prevent this)

  • Thanks for this suggestion, I'm definitely going to try this! Commented Dec 17, 2015 at 20:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .