Things Web Application Monitoring Can Pick Up From Casino Security

Security exists in order to protect the important things. While network security is constantly being upgraded in order to fend off attackers, it could actually learn a lesson or two from the surveillance of a casino floor.

Web-based security, especially for pay-to-play sites, uses multiple layers of protection. Betfair, currently the biggest Internet betting exchange, is one of the providers that use a 2-step authentication, intrusion detection systems, and other methods of security in order to solidly protect their customers. Unfortunately, sometimes, not even the strongest protections for sites are enough to prevent hackers from gaining illegal access and that is because of how threats are currently being handled by programmers.

The difference between web applications security and casino surveillance is this: when there’s suspicious activity, web applications tend to shut down ENTIRELY until programmers can identify the extent of the damage or the data that have been compromised. Casinos, on the other hand, handle the situation differently. Instead of the management shutting down the entire casino, it tries to contain the threat quietly in order to not upset or disturb its other patrons. If casinos operated similarly with web applications, its popularity would immediately decline and would probably be out of business soon. When a site is hacked and reported by the global media, people tend to stay away from it even if the site has been restored to normal. Response to threats is what web applications could primarily learn from casino surveillance.

The problem is that data gathered by most web servers today isn’t enough for conducting incident responses. Most of the time, request and response procedures are excluded from logging, which is kind of similar to a broken communication between a host and a server. The paper written by Gunnar Peterson titled How to do Application Logging Right, is a nice manual that can be followed in order to overhaul the common procedure in gathering data by web servers today.

To start improving the data gathering, web apps can act like casino cameras, which record all the data and store them for later use in case disputes happen. If there are any problems, casino management can simply review the tapes to help them identify the problem and culprit(s). In web application security monitoring, data gathering can be done through alert systems like AppSensor and then backed up with full audit logging.

When someone deviates from the norm (like when someone is suspected of card counting at the blackjack tables or when someone inserts an unusual card in slot machines), the casino management looks at the surveillance camera closely and zooms in on the suspect. This is similar to web app firewalls that have automated profiling and security procedures for the expected web app behavior. So instead of completely shutting down operations, what web app security can initially do is increase the audit logging and mark suspects while recording the traffic.

Web security shouldn’t only focus on completely eliminating threat without knowing what’s going on first. Hacks come in different forms and it’s better to have a closer inspection first on what they’re all about in order to have an idea how to counter them. It can be very dangerous to keep the enemy at bay without knowing what their plans are.

Event Based Cross Site Scripting Attack

I recently ran into a devious XSS attack, based on the onerror event. It can be done by exploiting other events as well, but the onerror event works particularly well, because the JavaScript is executed right as the node is rendered or appended to the page. Here is the attack:

<img onerror=alert(x); src=f
Then when the user content is appended or rendered in the page, the JavaScript executes. Replacing the alert statement with a ...