|
| Home | Accessibility | Courses | Diary | The Mouth | Forum | Resources | Site Map | About Us | Contact |
Robust checking of data entered by users
10 steps to testing the bullet proofing user inputs or how to avoid being caught by nasties when your script goes live!
1. Test it works with intended entries. It's not going to be much good if it falls over when someone entered a valid piece of data!
2. Test it works (fails correctly) with erroneous entries. Does it reject entries that should be rejected? Does it place the invalid text back in the form for the user to correct it? Does it also "sticky" the other fields, including selects, checkboxes and radio buttons, so that the user doesn't have to re-enter them? Does it offer a good explanation to the user of what the error was, and what inputs are acceptable?
3. Test it acts appropriately with inputs that include awkward characters and sequences such as < and " and ' and & and ../ and .htaccess ... and 3.5 and three where you've asked for a whole number. These are all important "security issues"; you should check that you're protected against ugly display echos if someone enters an HTML tag, SQL injection attacks, and file names that are reserved or navigate the directory tree.
4. Test it against a whole file of inputs There may be some "odd" cases you haven't thought of in the testing above. Do you have a whole file of data / inputs that you can run the script against? Example of what you might find - a user name gets confused with another user name that's a shortened form of it. I recall having "issues" with a computer called seal and another called sealion.
5. Test it works without cookies and on different browsers. This mainly refers to how the output looks, but if your user is refusing cookies, will the site be useable? Will he be irritated by being asked at every page? On different browsers, how does it look? And have you embedded any javascript or tags that are browser-specific and cause problems?
6. How do you implement your acceptable user policy? If your script is publishing the information entered on your site, how do you monitor for acceptable content? If it's a voting script, have you prevented one person rigging the system by multi-voting? If it's an online test, have you prevented your user selecting the back button and correcting his answers when you've told him he got a question wrong?
7. Have your colleague test that it works for him / her. Even with all of the above, you may overlook something. Or what is obvious to you might not be to someone else (e.g. is the submit button clear ...). Better to find this sort of thing out before you've got 000s of users.
8. Have the person who commissioned the script test that it works for him / her. Very much worthwhile having your paymaster on site, and after following the steps above the script should be impressibe in its robustness. Oh - and if it goes pear-shaped later, you did have the approval of the commissioner.
9. Release to some "tame" customers. Chances are that everyone who's used the script up to this point has been deeply involved and knows what it's about. Having a few customers look and provide feedback at a late stage will alert you to anything which is blindingly obvious in-house but not at all clear to Joe Public.
10. Release to the world. ... with a feedback link, and do make sure that you have a look at the log files and see the pattern of use.
(written 2005-08-27 09:09:55)
P609 - Perl - Network Security
H117 - Security in PHP
H115 - Designing PHP-Based Solutions: Best Practice
Y202 - Python on the Web
Charlie on Monday
Swindon - Chippenham - Melksham - Trowbridge - Westbury train service
The Melksham train - a button is pushed
Robust checking of data entered by users
Caching an XML feed
How not to run a forum
A Victorian Lady
PHP Magic Quotes
Don't repeat code - use loops or functions
This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.
Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).
1. Test it works with intended entries. It's not going to be much good if it falls over when someone entered a valid piece of data!
2. Test it works (fails correctly) with erroneous entries. Does it reject entries that should be rejected? Does it place the invalid text back in the form for the user to correct it? Does it also "sticky" the other fields, including selects, checkboxes and radio buttons, so that the user doesn't have to re-enter them? Does it offer a good explanation to the user of what the error was, and what inputs are acceptable?
3. Test it acts appropriately with inputs that include awkward characters and sequences such as < and " and ' and & and ../ and .htaccess ... and 3.5 and three where you've asked for a whole number. These are all important "security issues"; you should check that you're protected against ugly display echos if someone enters an HTML tag, SQL injection attacks, and file names that are reserved or navigate the directory tree.
4. Test it against a whole file of inputs There may be some "odd" cases you haven't thought of in the testing above. Do you have a whole file of data / inputs that you can run the script against? Example of what you might find - a user name gets confused with another user name that's a shortened form of it. I recall having "issues" with a computer called seal and another called sealion.
5. Test it works without cookies and on different browsers. This mainly refers to how the output looks, but if your user is refusing cookies, will the site be useable? Will he be irritated by being asked at every page? On different browsers, how does it look? And have you embedded any javascript or tags that are browser-specific and cause problems?
6. How do you implement your acceptable user policy? If your script is publishing the information entered on your site, how do you monitor for acceptable content? If it's a voting script, have you prevented one person rigging the system by multi-voting? If it's an online test, have you prevented your user selecting the back button and correcting his answers when you've told him he got a question wrong?
7. Have your colleague test that it works for him / her. Even with all of the above, you may overlook something. Or what is obvious to you might not be to someone else (e.g. is the submit button clear ...). Better to find this sort of thing out before you've got 000s of users.
8. Have the person who commissioned the script test that it works for him / her. Very much worthwhile having your paymaster on site, and after following the steps above the script should be impressibe in its robustness. Oh - and if it goes pear-shaped later, you did have the approval of the commissioner.
9. Release to some "tame" customers. Chances are that everyone who's used the script up to this point has been deeply involved and knows what it's about. Having a few customers look and provide feedback at a late stage will alert you to anything which is blindingly obvious in-house but not at all clear to Joe Public.
10. Release to the world. ... with a feedback link, and do make sure that you have a look at the log files and see the pattern of use.
(written 2005-08-27 09:09:55)
Associated topics are indexed under
P404 - Perl - Extending Flexibility Using CGIP609 - Perl - Network Security
H117 - Security in PHP
H115 - Designing PHP-Based Solutions: Best Practice
Y202 - Python on the Web
| Back to Caching an XML feed |
Previous and next or Horse's mouth home |
Forward to The Melksham train - a button is pushed |
Some other Articles
Linux commands - some basicsCharlie on Monday
Swindon - Chippenham - Melksham - Trowbridge - Westbury train service
The Melksham train - a button is pushed
Robust checking of data entered by users
Caching an XML feed
How not to run a forum
A Victorian Lady
PHP Magic Quotes
Don't repeat code - use loops or functions
1638 posts, page by page
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33 at 50 posts per pageThis is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.
Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).
PH: 01144 1225 708225 • FAX: 01144 1225 707126 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho