An apache module that would filter HTML results against XSS2 attacks? Preventing URL injection.
This could possibly be accomplished by finding all href/src attributes, parsing the url and applying htmlspecialchars to each value...without using regex just some simple string matching a module done in C could be pretty quick...probably faster than securing each parameter individually in PHP. This is of course just a guess...
Would it work? Under what situations would it not? Would you use it? Do you like the idea of centralized XSS filtering using an Apache mod?
The only problem that comes to mind immediately...is that it could break previous code...if you pass arguments/values to SQL and didn't decode html entities then your queries would stop working...
Opinions?
apache mod idea - what do you think?
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
You seem to believe that XSS attacks are mutually exclusive to href/src attributes.
And how would the module decide when it is appropriate to apply the htmlspecialchars() and when the data should remain as is.
2. Assuming that your module is only filtering href and src attributes, anywhere you display unfiltered data
3. Probably not
4. No, I want to avoid as many possible apache mod's as possible, the obvious reasons being you need the module installed making your applications less portable. With a half decent view layer, you should be able to apply auto filtering easily, and simply flag the variables you want to ignore filtering.
And how would the module decide when it is appropriate to apply the htmlspecialchars() and when the data should remain as is.
1. Probably notWould it work? Under what situations would it not? Would you use it? Do you like the idea of centralized XSS filtering using an Apache mod?
2. Assuming that your module is only filtering href and src attributes, anywhere you display unfiltered data
3. Probably not
4. No, I want to avoid as many possible apache mod's as possible, the obvious reasons being you need the module installed making your applications less portable. With a half decent view layer, you should be able to apply auto filtering easily, and simply flag the variables you want to ignore filtering.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I'm aware that XSS comes in a variety of "types" 1,2 and 3...to be exact.Jcart wrote:You seem to believe that XSS attacks are mutually exclusive to href/src attributes.
And how would the module decide when it is appropriate to apply the htmlspecialchars() and when the data should remain as is.
1. Probably notWould it work? Under what situations would it not? Would you use it? Do you like the idea of centralized XSS filtering using an Apache mod?
2. Assuming that your module is only filtering href and src attributes, anywhere you display unfiltered data
3. Probably not
4. No, I want to avoid as many possible apache mod's as possible, the obvious reasons being you need the module installed making your applications less portable. With a half decent view layer, you should be able to apply auto filtering easily, and simply flag the variables you want to ignore filtering.
My code is already well protected against type 0 and type 2...but type 1 (URL injection) is difficult to nail 100% at least within my architectural design...
Whenever I generate a element which has src/href attribute I am expected to htmlspecialchars each variable...I have 50+ templates and many cases those templates echo $request data (unfiltered) a dozen times or more...
With those kind of numbers...it's easy to slip once...
Securing the data against XSS anywhere else in the architecture doesn't make sense....I've tried it...it doesn't feel right. I could rely on programmer diligence but I think securing HREF like I describe above is a better more sure-fire way of protecting my application...
None of your reasons should affect my situation...It's a hosted application I have precise control over my environment. Apache mod's are favoured over PHP for pure speed and in this case centralization of security - at least against one type of exploit.
My view layer has proved to be extremely flexible, but perhaps I'm missing something...can you demonstrate how your view is configurable and capable of filtering against XSS type 1???With a half decent view layer, you should be able to apply auto filtering easily, and simply flag the variables you want to ignore filtering.
Please show it's use in both controller context and the view class itself...?
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Something as simple as:
The point being.. you don't trust the programmer (even if it is yourself). By making it filter by DEFAULT, you eliminate that risk.
When you say anywhere else, what are you referring to?
Code: Select all
class View
{
public function __get($name)
{
return htmlspecialchars($name);
}
//or
public function get($name, bool $filter = true)
{
if (!isset($this->data[$name])) {
return null;
}
return $filter ? htmlspecialchars($this->data[$name]) : $this->data[$name];
}
}I feel quite the opposite. That's like saying "I control my server settings so I'm not going to check for magic_quotes". It's called defence in depth.Securing the data against XSS anywhere else in the architecture doesn't make sense....I've tried it...it doesn't feel right. I could rely on programmer diligence but I think securing HREF like I describe above is a better more sure-fire way of protecting my application...
None of your reasons should affect my situation...It's a hosted application I have precise control over my environment. Apache mod's are favoured over PHP for pure speed and in this case centralization of security - at least against one type of exploit.
When you say anywhere else, what are you referring to?
Last edited by John Cartwright on Thu Dec 06, 2007 8:54 pm, edited 1 time in total.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I considered that approach...the problem is...it won't work under my architecture...Jcart wrote:Something as simple as:
The point being.. you don't trust the programmer (even if it is yourself). By making it filter by DEFAULT, you eliminate that risk.Code: Select all
class View { public function __get($name) { return htmlspecialchars($name); } //or public function get($name, bool $filter = true) { if (!isset($this->data[$name])) { return null; } return $filter ? htmlspecialchars($this->data[$name]) : $this->data[$name]; } }
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact: