2

I'm developing a browser(firefox) plug-in which essentially checks for malicious input. My current approach is to store all input fields sent in GET/POST requests, try to heuristically determine potential attack vectors and drop requests in case true positives are detected.

For data retrieval I've been thinking of implementing the functionality of tamper data. However, I cannot find a similar open source plug-in and developing one from scratch seems rather difficult(the only suggestions I've found refer to standalone proxies such as burpsuite and webscarab).

Any help would be greatly appreciated.

Sebi
  • 1,391
  • 9
  • 16
  • 1
    Who would be entering the malicious input? The user that installed the plugin? – Abe Miessler Nov 25 '14 at 18:56
  • The scenario is as follows: I administer a small computer science lab(12 boxes). I want to make sure that no attacks are being launched from those stations through the default browser(which in this case is firefox). – Sebi Nov 25 '14 at 18:58
  • OWASP ZED attack Proxy, or BURP free edition. – rook Nov 25 '14 at 19:09
  • So users cannot disable the plugins? – Abe Miessler Nov 25 '14 at 19:12
  • @Rook The application must be a plugin(the work environment is sandboxed and must not change)@ Abe Miessler no they shouldn't. Ideally they must not even know that such a plug-in is installed. – Sebi Nov 25 '14 at 19:19
  • Why cant you just check the server logs to see where the attacks came from via IP? Wouldnt that make a bit more sense? – Virusboy Nov 25 '14 at 21:37
  • @Virusboy Of course, but I'd rather prevent than fix. The plugin is much better suited for this purpose(the attacker does not know that the request has been dropped; on his end the it seems to have timed out). – Sebi Nov 25 '14 at 21:44
  • 2
    If the attacker is good enough to launch an attack, then wouldn't he be just as good to disable the plugin? Defense at the client side is never really a fool proof method. – user1720897 Nov 26 '14 at 08:56
  • Or use another browser? Or use curl or another tool? – xdhmoore Aug 28 '15 at 18:46

1 Answers1

2

This is a pretty scary thing to be doing, as by definition, you are wanting to look at sensitive, user-submitted data on those computers. Sure, you might catch the occasional wrongdoer, but you're going to be capturing quite a lot of normal people's passwords, emails, etc.

Which is probably opening a whole slew of liability to whoever owns the computer lab.

I'd contact your local legal department for advice here - its most likely better to go down the path of becoming a common carrier, and legally shielded from random user's activities, then it is to try and prevent them. Likewise, your plugin may become the target for a malicious actor, who can skip breaking into websites, and just capture the data from your tool.

Ryan Gooler
  • 759
  • 4
  • 9
  • The lab session is roughly one hour long and quite strenuous(there isn't a lot of time to get around the security of the plugin). This is hardly a security constraint but the reason to develop this plugin is due to the fact that a number of attacks have originated from those workstations. Students are logged on with their university credentials. Data is not stored internally, all input is processed on the fly and discarded immediately afterwards. The plugin is not meant to be noticed only to identify potential malicious behavior. – Sebi Nov 25 '14 at 21:10
  • So, you have reported attacks (from online sites I imagine), and logs of who was using what computer at what time. I think you can spend a LOT of time and effort trying to make a preventative control, or you can spend your time making a tool to quickly identify unique machines in the lab, given a time when an attack took place, and the IP that was hit. You should have the network logs to turn that into a computer, and then a username. And, again, I urge you to consult with legal advice, as trying to do more can be MUCH more trouble than its worth. – Ryan Gooler Nov 27 '14 at 10:40
  • Yes, checking the logs is definitely a solution. However, there are four NAT devices between the lab and the Internet. It takes a lot of time to pinpoint the exact workstation from which the attacks were launched. I have been using this approach for some time and there are cases when necessary logs are being deleted at the upper level NATs due to high bandwidth usage and storage constraints making tracing impossible. The plug-in should offer a better image of web traffic and a higher level of granularity. – Sebi Nov 27 '14 at 22:28