An injection attack is where information supplied within a table entry box or upload file is used for malicious purposes - for example, if a user enters his name as fred'; drop database test; etc ... and finds that the script he has contacted inserts the text entered into a database query. Possible injection attacks include:

* HTML, where an abuser fills in tags into a data entry box. Leads to poorly displayed information when the tags are echoed back to his (or other users) pages. Solution - htmlspecialchars

* Variable seeding, where an abuser adds an extra box to the HTML source and initialises one of your variables that you have failed to initialise in your code. Scripts which are easily accessible in source form are prone to this form of attack if poorly written, but only if you're running PHP4.0 or earlier, or if you've set register globals

* JavaScript, where Javascript is filled in to a box and echoed back. The problem then is that the Javascript may be seen as having been supplied by the server so can access the server without the usual security restrictions.

* SQL, where SQL is entered into a box - my example in the into paragraph shows an SQL attack example although I haven't given you the complete code. Once again, these attacks are much more likely to succeed on scripts where the source code is commonly available.

Both the Javascript and SQL attacks can be prevented by default if the "magic quotes" setting is on - which by defaut it IS on recent versions of PHP. If, however, you stripslashes an input so that you can echo back O'Brien and not have it come up as O\'Brien, then you'll need to ad slashed back in for storing in a database, and check scripts that echo back input to ensure they're not sending Javascript

* File name, where the user's input is taken as being a file name or the basis of one. If I enter my name as "../graham", for example. I you must take the user's input to form a file name, filter it carefully!

* Email header, where a subject line or recipient can be specificed that's used as extra parameters to the mail() function. Subject lines that include a new line character can be used to add a "cc" to "bcc" header unless you check it, and if your email script does not email you each time it's used, then you can be unaware that your site is being used to send out unsolicited material for years!

Although all of the coding traps that allow you to leave you site open to attack were easily present on earlier versions of PHP, it's hugely improved now. Variable seeding, Javascript and SQL attacks are turned off via default server configuration options "register globals" and "magic quotes" that you will find in the server's php.ini file.
(written 2007-02-20 05:28:26)

 H117 - Security in PHP

Back to Lawrence Webb's Melksham Taxi service

Previous and next or Horse's mouth home

Forward to Telling a story in different ways

Too many instructions, too much detail
Playing old games
Why use BBC code not HTML?
Telling a story in different ways
Injection attacks - safeguard your PHP scripts
Lawrence Webb's Melksham Taxi service
Writing terms and conditions for conferences and other events
Behind the scenes
Straight from the .jar
Customer takes over class, and I am delighted
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 page


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