| 12:17 pm on Jan 17, 2013 (gmt 0)|
hash keys for arrays are case-sensitve.
<input name="Email" type="text" size="60" class="Contactboxes-email" id="Email" value="<?php echo $_POST['email']; ?>"/>
See the "Email" used to send it to you and the "email" used to send it back ?
That said, this is a classic example of a website vulnerable to Cross Site Scripting (XSS) - well at least once you fix this.
| 1:20 pm on Jan 17, 2013 (gmt 0)|
That works perfectly.
You're a star.
| 3:44 pm on Jan 17, 2013 (gmt 0)|
I hope you fixed the XSS security bugs. Remember that any XSS affects your entire site - not just the vulnerable element itself.
| 2:17 pm on Jan 21, 2013 (gmt 0)|
What XSS security bugs? and how do i fix them.
With the form, if the user has filled out the form successfully, a message says that it has been sent, but the data in the fields is still there. Any way to correct this?
| 3:06 pm on Jan 21, 2013 (gmt 0)|
Anywhere where you send back unfiltered input is a XSS vulnerability.
How to fix them see the link to oawsp above for a comprehensive answer.
In essence: make sure there is no html in the input that goes back to the user - yes that's all it takes to have a XSS vulnerability.
Simply changing < > " ' and & to their respective htmlentities is enough in the cases you've shown so far.
htmlencode() is ok too - but it's not a generic solution in all possible cases - you should escape those things that in the context of where you output them can hurt you.
| 3:44 pm on Jan 21, 2013 (gmt 0)|
Will this correct the issue of data still be there once the user has clicked on "Send" and all the fields are completed correctly?
| 5:49 pm on Jan 21, 2013 (gmt 0)|
It doesn't matter that you do not echo back upon success, any way there is a possibility for echoing back unfiltered content is more than enough for an attacker to exploit it - even an error page is plenty of an opportunity.
The attacker does not need to use your form ... they can make their own (it might even not look like a form at all just a button or link is enough for them. If you process the input and send unfiltered output back: you lose (and/or your users lose).
Don't output unfiltered user input: running it through htmlencode() before you output it. will remove most of the problems. Actually: there are functional problems solved there too.