4 ms·
Firewall Script - No more hacked PHP sites?
- ivank 19y agoClient Testimonal - right from the homepage: > People think my site is weird because it's about the supernatural. But they're out there! Sometimes the extraterrestrial see our website and try to hack it to avoid the information we reveal about them. However, since we purchased FirewallScript, we haven't had a problem since. [...]
- Hexstream 19y ago"Once installed, you can configure what mischevious things you want to be on the lookout for and let FireWall Script do the rest. With the logging functionality included, you can also go back and see if anyone is attempting to sidestep your rules and stay ahead of the game." Isn't that a case of Enumerating Badness (http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d...)? Why not instead have strict rules about what you allow? It's telling they suggest you "stay ahead of the game", it sounds more like "play catch up in the arms race because your design is inherently insecure" "Testimonial: Being a very old website, it comes hard to update because of the potential risk. So we often risk hackers everyday because we run unprotected. Now that we use FirewallScript, updating is not required for security and protection because we have it in this easy, fast script." I don't think you can juste substitute a simple script for competence and sound, robust design like that... I don't drink this kool-aid.
- paulgb 19y agoThere doesn't seem to be any explanation of how the software works. Seems like snake oil to me.
- frankus 19y agoAre there any web frameworks out there with really solid access controls baked in? As an unprivileged user on a UNIX box, if I maliciously or inadvertently screw something up, about the worst thing I can do is blow away my home directory or maybe soak up enough machine resources to make everyone else's processes slow down. As an unprivileged user on a poorly-secured web app, I can potentially blow away pretty much anything that the web server and/or database user has access to. Granted, creating a new database user or shell account every time someone signs up for something like, say, Twitter probably wouldn't scale. But a carefully-written web app environment that could scale to millions of users (each with privileges to see/alter only their own data) sure would be nice. I suspect the place to do this would be at the data store level, where (for instance), given a login cookie the app could obtain a set of capabilities on only the data that the user has access to. It would change the default allow that seems to be the current practice into more of a default deny. Anyway, I'm rambling now. I'll stop.