6 ms·
I had a client once who had something similar, although unintentionally. She approached me because her website "kept getting hacked" and she didn't trust the or
by tonyarkles 12y ago
I had a client once who had something similar, although unintentionally. She approached me because her website "kept getting hacked" and she didn't trust the original developers to solve the security problems... And rightly so!
There were two factors that, together, made this happen: first, the admin login form was implemented in JS, and if you went to log in with it with JS disabled, it wouldn't verify your credentials. And it submitted via a GET request. Second, once you were in the admin interface, you could delete content from the site by clicking on an X in the CMS. Which, as was the pattern, presented you with a JS alert() prompt before deleting the content... via a GET request.
Looking at the server logs around the time it got "hacked", you could see GoogleBot happily following all the delete links in the admin interface.
- brador 12y agoWhat's the idea solution for this? I would drop a cookie and use that to verify admin privileges on each page. Is that right?
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- jessaustin 12y agoFirst, use the correct HTTP verb: POST (or possibly DELETE). Googlebot only GETs. Also as you note, destructive changes should be authenticated, whether by Basic Auth over TLS or the more common cookie tokens.
- Mahn 12y agoAuthentication, POST requests and CSRF tokens, at the bare minimum.
- ben0x539 12y agoFundamentally, authentication when someone tries to delete a thing needs to happen in server-side logic, not on the client side. The rest is flavouring.
- vkjv 12y agoAuthentication should happen server side, but authentication need not happen at the time of delete. When deleting, you should be authorizing and validating, which can safely be done client side... but, if you are doing something server-side (e.g., a delete) you should also be doing it server side.
- TillE 12y agoHTTP is stateless. You need to generate some kind of token that can be checked for each admin action a user takes.
- tlrobinson 12y agoBasically do the exact opposite of everything they did. Doing authentication in client-side JavaScript is an absolute no-no. Using GET requests for things that have side effects (like deleting content) is another.
- Apofis 12y agoDon't authenticate on the client, it's that simple. Authenticate only server side.
- airtonix 12y agoSolution is to use a mature web framework that already solves this. ie. Django.
- toxicFork 12y agoSomeone should make a website for indexing bots to play with!
- ikeboy 12y agoAre you this guy http://thedailywtf.com/articles/The_Spider_of_Doom http://thedailywtf.com/articles/The_Spider_of_Doom? Or http://craigandera.blogspot.com/2004/04/beware-googlebot_12.html http://craigandera.blogspot.com/2004/04/beware-googlebot_12....? (They seem like the same story but have different names.)
- robflynn 12y agoProbably not. This happens more than you might think. I got called in to consult on a project where something similar was happening. Client would add products to their web store and the next day the products were missing. Unsecured access and 'GET' based deletes were everywhere.
- kragen 12y agoI accidentally deleted about half of the database at a startup where I’d recently started working by approximately the same method. I was running a copy of the web interface on my laptop, connecting over the internet to our MySQL server, and also running ht://dig’s spider on localhost from cron. It started spidering the delete links. Fortunately, I’d also started running daily MySQL backups from cron (there were no backups before I started working there), so we only lost a few hours of everyone’s work. As you can imagine, though, they weren’t super happy with me that day.
- frandroid 12y agoIf they weren't making backups before, and you instituted them, they should have been super happy with you.
- kevin_thibedeau 12y agoCowboy coders don't like to see the holes in their development process.
- kragen 12y agoThey were unhappy to lose several hours of the rest of the company’s work.
- ars 12y ago> I had a client once who had something similar, although unintentionally. I did that too. I was aware of the problem, but at the time (1996) I did not know how to fix it. So I just documented it and warned that they should keep the site away from altavista. This was back before cookies had wide support, so login state was in the URL. If you allowed a search spider to know that URL it would have deleted the entire site by spidering it. I did eventually fix it by switching to forms, and strengthening the URL token to expire if unused for a while. And then eventually switching to cookies (at one point it supported both url tokens and cookies). I have not thought about those days in such a long time.
- deleted 12y ago[deleted]
- sukilot 12y agohtaccess would have been your friend. How did you prevent any visitor from deleting the site?
- ars 12y ago> htaccess would have been your friend htaccess didn't exist in 1996. This site ran on IIS 1.0 on Windows NT 3.51. For scripting we used a prerelease Coldfusion version. (i.e. the version before 1.0, which was released as we were developing the site, partially based on feedback we provided as we tested it.) > How did you prevent any visitor from deleting the site? A security token in the url which was secret. The worry was that some admin would try to submit the site to altavista for indexing without removing the token from the url first.
- zerocrates 12y ago> htaccess didn't exist in 1996. Obviously not for IIS, but .htaccess files go back at least as far as NCSA httpd, and so definitely existed before 1996.
- airtonix 12y ago> This site ran on IIS (anything) There's your first problem.
- CodeWriter23 12y agoYou win "Most Hilarious Bug" for the day.
- tonyarkles 12y agoClearly! I just came back to HN and wondered what the hell had happened to my karma.