hijack

Just got a comment hijack. Javascript that killed off the comment. Anyone seen this?

Re: hijack

I am not sure I follow. Can you give some more details? Thanks, Scott

Re: hijack

I should have pulled the message out of the database. The message was simply: "your link hijacked" and had a link inside the message. The link was javascript that called whatever procedure you have in place to delete a message. Clicked the link and the message got deleted. I've got the .95 source, but I've never looked at it (haven't had the time) but would be interested in changing the call to something unique so someone couldn't go around and embed other message numbers into a javascript link and start deleting other posts. I hope that makes sense.

Re: hijack

hmmmm that's an interesting approach... Anyone else seen this occur anywhere?

Re: hijack

Yeah it certain was. If I had been thinking clearly (was a looong day) I would have pulled the message from sql before clicking the link.

Re: hijack

Semi-interesting. Two separate issues. 1. Yes, it looks like the 095 codebase would allow a non-admin to remove a comment if a malicious link can be inserted into the database (which is issue 2). So, if you insert the following Text into a comment, you insert a link that deletes the fixed index (of the control) comment.

This is a hijacked link test.

By dint of ctl0, first comment in the list gets deleted. There is no client side script for removal, this is just posting back to the right event handler in the comments control. So first step in hardening it would be to modify the event handler to check for admin permissions before removing. (It should do that anyway). In Comments:

protected void RemoveComment_ItemCommand(Object Sender, RepeaterCommandEventArgs e) 
{
	if(Request.IsAuthenticated && Security.IsAdmin)
	{
		int feedbackItem = Int32.Parse(e.CommandName);
		Entries.Delete(feedbackItem);
		Response.Redirect(string.Format("{0}?Pending=true",Request.Path));
	}
	else
	{
		// this is reactive, the security should be inbound. nonetheless,
		// a security issue has taken place, should notify or self-address.
	}
}

That would, at a minimum, prevent a non-admin user from removing a comment. To prevent an admin user from being duped into removing a comment by clicking on a malicious link, you would either need to add a client-side confirm dialog or do an interstitial confirm page on the server (both of which are done elsewhere in .Text and can be leveraged). 2. That said, I wonder how the link got into the comment body in the first place. To test the link above, I had to hand enter it into the database directly. Posting it interactively is going to encode/decode it into html entities thereby neutralizing it. Which is a bigger concern (and it's where this kind of threat should be really addressed, although the reactive fixes above are so inexpensive, it would be silly not to implement them). I'm not being real creative on how the link could be making it into the database in a live context, but if that indeed can happen, then that's a bigger security issue that should be addressed. Imo, the problem here really isn't that someone embedded a specific javascript call in a comment, it's that they embedded executable javascript at all.