The Usability of Input Filtering
March 31st, 2005There seems to be much interest lately in input filtering in PHP, especially in cross site scripting prevention. I've always preferred input validation to input filtering, but I am giving filtering a new examination. My problem with filtering is with usability. The comments to this post are a good example. There are obviously some usability issues going on here.
I think the fundamental problem with input filtering and especially XSS filtering is that it violates the principle of least surprise. User input is silently modified without the user's knowledge. If the violation is innocent, then the software surprises the user. This is bad. At least with validation, the user gets a heads up on the problem.
Let me try to name and enumerate some scenarios:
Direct Filter
This is what WordPress did in the example post. It simply accepted the user input and silently changed it. The filtered value is stored directly into the database. The original input is lost. There is no preview. I think this has to be a usability worse case scenario.
Filter with Preview
This scenario adds a preview capability to the last. The filter is still applied. A validation failure or explicit preview button causes the form values to be re-displayed and a preview panel to be shown. However, the previous input value is silently modified and sent back to the user. The user may or may not realize that his original input has been changed during the round trip.
This is also seems like a usability problem, but every once and a while it happens to me when entering legitimate input into professionally written programs.
Filter with Buffered Preview
This scenario adds an additional buffer to the last. The filter is applied, but the original input is sent back to the user in the form field. However, the preview panel shows the modified value.
I don't really see this very often outside of fields with a dedicated markup language (for example BBCode).
Filter with Forced Preview
The input value is silently filtered. However, the user is forced to preview the output at least once. Its up to the user to notice the results of the filter.
I think slashdot does this.
Filter with Confirmation
A stricter variation of Forced Preview where as the last stage, the user must confirm their input once without the ability to change it. It is up to the user to notice the results of the filter.
I think this is popular as the last stage of a wizard style interface.
Filter with Confirmation and Warning
The filter is applied and the user's input is changed, however, the user is warned exactly which value was changed by the filter.
I don't think I've ever seen this one.
Validation
The program notifies the user that the input value is bad, but does not modify it. The user must change the value to proceed.
I tend to use this one. I escape all output, so I don't worry too much about displaying XSS in the preview panel.
Obviously, you can mix and match scenarios for different input rules and fields. I'm sure there are other scenarios. Please suggest some.
I guess I've been programming for about 23 years now. The longer I do it, the more reluctant I am to be strict with user input. Ultra sanitized, ultra structured data may seem attractive to the programmer, but its a pain for the user and its only a matter of time before a legitimate exception comes along. A European phone number, the 51rst state, a canadian postal code, a new millennium, etc. The exception is the rule. Understandably, XSS must be prevented, but its easy to go too far.
Which of these scenarios do you think are best from the user's perspective? From the programmers perspective?
All Posts
April 1st, 2005 at 1:54 pm
Hmm interesting issue. I guess I like the Filter with buffered preview best. You apply the filter, don't change the users original input and allow him to learn from his mistakes by changing the original input to learn how to do it right in one go the next time. This way the user is aware of the filter and will even learn how it works. Software that quite painlessly educates the user on how to use it. Sounds great!
April 1st, 2005 at 5:48 pm
I'm a little confused by "Filter with Confirmation." Why would you bother showing somebody a preview if they can't change it? What would the point of the preview step be then?
April 2nd, 2005 at 8:04 am
seth, the only think I can think of is the fact that they can at least cancel it if the output is something completely different than they wanted.
April 2nd, 2005 at 8:10 am
Marco, consider that for infrequently used applications, especially web applications, any learning forced on the user is not painless. A user may never have seen your software before, and perhaps will never again. However, I do think "Filter with Buffered Preview" is a good option for infrequent use.
User input is not disturbed. No surprises there. One has to assume if the user hits the preview button that the user will inspect the resulting preview panel for correctness. The only chance for surprise is if the user chooses to directly submit without a preview.
April 2nd, 2005 at 8:16 am
The reason "Filter with Confirmation" is stricter than "Forced Preview" is that with forced preview you could have the following sequence of events:
1. Fill out initial form.
2. Click preview (no other option available)
3. Change form values
4. Click Submit.
There is still chance for surprise here because there was no preview required after form values were changed in step 3. "Filter with Confirmation" requires at least one stage at the end where there is no chance that a user change might result in a surprise filtering.
I think this option works best with infrequently used forms. (Like wizards, surprise, surprise.) Requiring confirmation in commonly used scenarios just trains users to ignore and become annoyed with the confirmation stage.
April 2nd, 2005 at 8:51 am
Filter with Buffered Preview, then a twist.
I'm not sure how relevant this is to the topic. I take user input in the style of 'tell us if you see an error on this page' input - and poeple like to swear and hit "send", too tempting for them, see?
So I have a profanity filter switched on to catch all the rude words and spare admin users blushes.
So we ALLOW the users to swear, and show them their naughty input and they continue thier sad lives, thinking they have struck one for liberty - but if fact I comment out all the bad chars before storing it. Without that confirmation they figure out other ways of getting their msg across.(e.g separate letters with s p a c e s)
So heres a case where you would want to do hidden filtering, and yet show the user their original comment.
As ever in the UK, this won't work in Scunthorpe.
April 3rd, 2005 at 8:27 am
The best solution is none of the above, it is to treat variables as attached to a certain context.
When changing context (sending them to the DB, using them in the Shell or outputing in a XHTML page) make a context transition (usually escaping control characters)..
Something that smells bad about all the above solutions is that if you do a site for storing XSS attacks, information or whatever all the above alternatives would catch this as threatening input.
Another issue is that although most of these methods would catch one potentially dangerous variable, it would not catch if 2 variables would appear in the same page near one another it could still be possible to exploit it
(you could open the tag and leave one of its properties open until you close it in the next tag, completing the necessary code for the exploit).
Remember that good XHTML has only "" as attribute markers, well browsers still accept '', so in the new and well done XHTML compliant applications it is trivial to do such a exploit...
BTW, i am totally for XHTML, just think the way to security is more along the context evaluation route...
April 3rd, 2005 at 11:44 am
Filtering and validating are the same. Filtering is the formal term that has been adopted by the security community, but there are many synonyms in common lore: validating, cleaning, scrubbing, etc.
There is a security principle that says that we should never modify invalid data in order to make it valid. Therefore, filtering (by any name) refers to an inspection process. This is why you'll never see me recommending the use of strip_tags().
All XSS and SQL injection vulnerabilities I've seen are due to a failure to escape output. I'm glad to see a heightened interest in filtering input, but I hope it doesn't distract people from the equally important step of escaping output.
August 1st, 2007 at 7:17 pm
To make life easy for moderators, you can use a script to highlight anything that might be an issue. I am working on this for my own site.
I have to disagree with Chris Shiflett. Validation is YES or NO. there is no in between. Filtering can do a combination of things such as:
a) allow everything
b) allow certain things (white list)
c) deny certain things (black list)
d) change certain things
Validating and filtering are comparable to a lens cap and a filter on a camera.
-Frank
March 22nd, 2008 at 2:20 pm
Hello everybody, my name is Damion, and I'm glad to join your conmunity,
and wish to assit as far as possible.