Page 1 of 1
apache mod idea - what do you think?
Posted: Thu Dec 06, 2007 8:00 pm
by alex.barylski
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?
Posted: Thu Dec 06, 2007 8:10 pm
by John Cartwright
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.
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?
1. Probably not
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.
Posted: Thu Dec 06, 2007 8:28 pm
by alex.barylski
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.
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?
1. Probably not
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.
I'm aware that XSS comes in a variety of "types" 1,2 and 3...to be exact.
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.
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 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???
Please show it's use in both controller context and the view class itself...?
Posted: Thu Dec 06, 2007 8:47 pm
by John Cartwright
Something as simple as:
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];
}
}
The point being.. you don't trust the programmer (even if it is yourself). By making it filter by DEFAULT, you eliminate that risk.
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.
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.
When you say anywhere else, what are you referring to?
Posted: Thu Dec 06, 2007 9:01 pm
by alex.barylski
Jcart wrote:Something as simple as:
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];
}
}
The point being.. you don't trust the programmer (even if it is yourself). By making it filter by DEFAULT, you eliminate that risk.
I considered that approach...the problem is...it won't work under my architecture...
Posted: Thu Dec 06, 2007 9:37 pm
by John Cartwright
What IS your architecture?