-k
i'd need more information than is in this letter to really pose a possible solution, but i took a gander at their site and have this advice:
malicious code can be entered in forms, and it is not a new concept. there are steps you can take to limit the risk that you subject yourself to when you use a form post method. (i am working under the assumption that the source of some of the problems is http://www.indymedia.org.il/imc/israel/webcast/publish.php3 and pages with similar code, like discussion areas.)
on the surface, your problems will arrive in one of two forms: 1. a malicious user inserts client side code (vb script, java scrript) that is executed by browsers when the "comments" containing the client side code are read by a browser. 2. a malicious user inserts server side code (using php in this case, sice the site runs php) and when the page is requested, the interpreter on the server renders the page prior to presentation to the browser.
this can be challenging to deal with, but it is not impossible. there are a variety of options one can choose from to deal with this, and those that follow are in no way meant to represent a complete list, but rather i am merely presenting one option or many.
when dealing with client side scripting being entered into forms, those scripts *require* a beginning and ending tag in order for the browser to recognize them as code, and not standard HTML. the trick is, of course, to recognize them yourself *before* you present them to the browser. because PHP is interpreted on the server prior to presentation, this is your opportunity (your only opportunity) to intervene. this requires that a php function be called with any user entered data is it's parameter.
define the function as such: <? function validate_user_form($UserEntryData)
//this function calls functions like preg_match, ereg, and eregi to look //for the patterns that precede client side code, like <SCRIPT> and //<SERVER> as well as phrases like "public boolean" and "import java." //if it finds a match, it can remove the offending code, or just choose to not //post the entire submission. review the "bad" submissions to fine tune your code. //another option is to explicitly specify the allowed code (as i noted that the forms allow the submission of html), if code does not match the allowed code, then the submission is suspect.
end function ?> this function then, validates the users entry prior to presentation. also look at the escapeshellcmd function and related functions.
preventing users from utilizing server side php can be as simple as searching the users submission for "<?" and "?>". or, render the page as HTML only, with *no* php interpretation prior to presentation, the php will not be executed.
ultimately then, the solution is found in verifying and validating user input.
hope this helps.</quote>