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.
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.
EliteCoders
Member
35 Points
7 Posts
hijack
Aug 18, 2004 09:59 PM|LINK
http://www.builderpinions.com
http://www.handlinfamily.com
ScottW
Contributor
3651 Points
730 Posts
ASPInsiders
Re: hijack
Aug 20, 2004 12:33 AM|LINK
http://www.scottw.com
EliteCoders
Member
35 Points
7 Posts
Re: hijack
Aug 20, 2004 02:18 AM|LINK
http://www.builderpinions.com
http://www.handlinfamily.com
christoc
Star
8562 Points
1566 Posts
Re: hijack
Aug 20, 2004 05:53 AM|LINK
DotNetNuke Upgrades and Consulting
EliteCoders
Member
35 Points
7 Posts
Re: hijack
Aug 20, 2004 02:04 PM|LINK
http://www.builderpinions.com
http://www.handlinfamily.com
grant
Participant
935 Points
185 Posts
Re: hijack
Aug 20, 2004 05:43 PM|LINK
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.