restricting the tags is not enough - you need to restrict the attributes as well e.g. onclick.

once again htmlpurifier is what you need. http://htmlpurifier.org/

ya i have downloaded that and having look at it...

are you trying to suggest,once we use html purifier ,we can take html input freely.
or does it mitigate all known threats till now? (we agree there may be many more threats unless it comes to light)

and
we have some old scripts running in old php ie 4.3
does the package support php 4.3?
i saw it site,it says php5....

any way thanks

how and why ...that is what i am trying to know.

Are programmers trying to suggest that, there may be uncountable numbers of threats ,once we allow html which cannot be mitigated(or no one has been able to mitogate all ....) so best idea is to block html .

GENERALLY BBCODE IS EASIER BECAUSE IT AUTOMATICALLY DISALLOWS ANY PURE HTML VERSUS ALLOWING 'SOME' HTML
ASIDE FROM SECURITY, THERE'S ALSO LESS SCOPE FOR USERS SCREWING UP LAYOUTS BY ALLOWING <p>, <div> TAGS ETC

what are we trying to say is,
ok if there were n(countable) numbers of threats we could just counter those( for eg, disallow script,iframe tags ..so on) and allow html freely...but we are not...
so, does it mean that ,if we allow html ,nobody knows how many problems may be there or where the crack attempt may come from...so just block it...

YOU -COULD- ALLOW SOME LIMITED HTML TAGS IF YOUR SERVER-SIDE VALIDATION ENSURES THAT ONLY THE SAFE ONES GET THROUGH E.G. <b>, <i> etc

THE PROBLEMS WOULD ARISE FROM <SCRIPT>, <IFRAME> ETC TAGS, IF YOU CAN BE SURE TO STRIP EVERYTHING THAT COULD DAMAGE THE SITE THEN HTML IS SAFE


ok though tiny mce is client side...it does have strong config option which allows control its behaviors...we were trying to know was,if there were any to control html input...

if i write the javascript function,i will be doing client side once again....so, if i HAVE to do it in server side...there are many php fuctions for it...i would prefer them...

SO DON'T DO CLIENT SIDE VALIDATION, YOU DON'T HAVE TO, AND IT'S NOT REALLY HELPFUL FOR YOUR USERS IN THIS CASE (SINCE THEY WOULDN'T BE CONSCIOUSLY INPUTTING RAW HTML ANYWAY)

SERVER SIDE VALIDATION SHOULD ALWAYS BE DONE REGARDLESS OF WHETHER CLIENT-SIDE VALIDATION IS


ok, what we were trying to ask was, if they both are equivalent ,why are many sites,scripts not choosing the better option (means having button is much easier)....
does ,not using button has any significance...?
or it is just their negligence....
i have seen those in big sites, even must wordpress and other script comments...

I GUESS SOME PEOPLE ASSUME THEIR USERS HAVE A RUDIMENTARY KNOWLEDGE OF BBCODE OR HTML AND SO DON'T USE THE BUTTONS, THAT'S ALL
OR THE PROGRAMMERS WERE TOO LAZY TO INSERT THEM OR DIDN'T HAVE THE JAVASCRIPT KNOWLEDGE

any way thanks for thought
just discussion....

YOU -COULD- ALLOW SOME LIMITED HTML TAGS IF YOUR SERVER-SIDE VALIDATION ENSURES THAT ONLY THE SAFE ONES GET THROUGH E.G. <b>, <i> etc

THE PROBLEMS WOULD ARISE FROM <SCRIPT>, <IFRAME> ETC TAGS, IF YOU CAN BE SURE TO STRIP EVERYTHING THAT COULD DAMAGE THE SITE THEN HTML IS SAFE

SO DON'T DO CLIENT SIDE VALIDATION, YOU DON'T HAVE TO, AND IT'S NOT REALLY HELPFUL FOR YOUR USERS IN THIS CASE (SINCE THEY WOULDN'T BE CONSCIOUSLY INPUTTING RAW HTML ANYWAY)

SERVER SIDE VALIDATION SHOULD ALWAYS BE DONE REGARDLESS OF WHETHER CLIENT-SIDE VALIDATION IS

I GUESS SOME PEOPLE ASSUME THEIR USERS HAVE A RUDIMENTARY KNOWLEDGE OF BBCODE OR HTML AND SO DON'T USE THE BUTTONS, THAT'S ALL
OR THE PROGRAMMERS WERE TOO LAZY TO INSERT THEM OR DIDN'T HAVE THE JAVASCRIPT KNOWLEDGE

we have some old scripts running in old php ie 4.3

You have some potential security holes right there. You should consider upgrading to PHP 5 ASAP as that is the only version of PHP still supported and any security holes discovered in any PHP 4 version will never be fixed.

so remaking whole site for them in new version of php is difficult...

php 5 isn't so different to php 4 that it will require a complete rewrite.

just try it out and you could probably fix any issues quite quickly.

thanks
and that is excatly what we are trying to know...
means
even us,speaking at large,we also dont see much difference in php 4 and 5 .(unless we hadn't covered basic securities things in our php 4.3 coding),means
we see in php 5
there are some more function that eases the task
the way the things are coded have changed....like mvc ,cake php and many other frameworks ....which allows reusing
and php 5 seems to be based on future easy expansion and "dont reinvent the wheel" concept...other than that we dont feel much difference is 4 and 5

so, what excatly are things we should do ?....when we say ..lets change thing to php4 to php5 for security..?
any examples..?
means ok, earlier projects seems to rely on register globals,$_REQUEST super variable...which use to cause problems..(we dont use those)

so ,what can be other problems that php 4.3 was not able to address/solve and we need to change...

any function,super varibales, constructs, style that had problem in itself in php 4.3?

thanks

the point with security is that php5 in itself is inherently more secure than php4. vulnerabilities that arise are not necessarily a problem with php code but with php itself.
.

now,first question,
programmer really seems to fear html code,we found forum allowing only bbcodes, other scripts not allowing html ....
so do we really need to disallow users from using html in form data....

2nd question)
we have decided to only bbcode only for users for now,does package like tinymce allow disabling html and allowing bbcode only...
any problems with this logic?

3rd question)
we have seen most big sites making people type the bbcode in comments....what is it advantage...why cannot they put button to generate bbcode as in forum...
has it something to take with security....?

any thoughts would be helpful
thanks

for eg...?

you can say it technically ,we do understand php....

giving an example of a problem is better than saying there is a problem...

any way thanks

You can also check out this class from pear, it offers pretty good protection against dangerous html. It will just remove the dandgerous tags, leaving the rest of html.

I use it in my project and I allow users to submit blog posts with html in them.

http://pear.php.net/package/HTML_Safe

I also made some changes to this class to make it work nice with php 5, but it will also work as-is, just will throw warnings under E_STRICT

Right, HTML_Safe has not changed singe December 2005, but there has not been any new html tags added since then and has not been any bugs filed for this package, meaning it works well.

Also, it will work with php 4 and 5

Right, HTML_Safe has not changed singe December 2005, but there has not been any new html tags added since then and has not been any bugs filed for this package, meaning it works well.

Also, it will work with php 4 and 5

1) User-supplied html code can potentially be harmful if it includes things like javascripts, iframes, divs (which can wreak the layout), but if you restrict the html to things like <b>, <i>, <ul>, <li> and be sure to remove tag attributes I can't see a problem?

2) http://tinymce.moxiecode.com/examples/example_09.php
so - yes
however you'd still have to strip any html tags server-side.

3) there's no difference between typing the bbcode and having a button click insert [ b ][ /b ] for example, security shouldn't be compromised if the input is filtered. really a matter of convenience

i clearly understand that but what we are trying to know is.....almost 95 percent people/experts/sites are seems to be saying ,there is no way to be safe with html input...none of scripts allows it(i have not seen any article system that allows html),most big cms doesnot allow html in comments....so it is giving feeling as if there are no ways to cope with html input...
even this forum (vbulletin)...why bbcode ..? but not limited html...?

BECAUSE IT IS GENERALLY SAFER TO DISALLOW ALL HTML AND USE BBCODE TO MARK UP CONTENT (PLUS IT'S EASIER THAN MANAGING LIMITED HTML)

i have seen that...one thing we didnt understood was ,by default it would allow html inputs....so some crackers will try those may be typing them...so how can i disable html(whole html) and only allow bbcode in tinymce from config(u may ask ,whats its use then....we will have full editor in admin...and bbcode only editor in public)
mind u ,strip_tags is not tinymce solution ....so is it only way...?

TINY MCE IS CLIENT-SIDE - IT WON'T STOP PEOPLE INPUTTING HTML INTO ITS TEXTAREA IF THEY WANT TO, INPUT VALIDATION --MUST-- BE DONE SERVER-SIDE. YOU COULD WRITE A JAVASCRIPT TO SEARCH THE TEXTAREA FOR HTML TAGS BEFORE IT'S SENT TO THE SERVER BUT THIS CAN BE BYPASSED. SERVER SIDE FILTERING WITH STRIP_TAGS OR WHATEVER IS ESSENTIAL

There is huge difference...all people are not computer greek like u ....we have some article readers who are using computer for first time.....(but many have used word processor like ms word...which has bold,italics button)...
and saying to type <..b> and close it <../..b> and clicking button (that generate those code) are very different things....
not all knows html....

I WASN'T ARGUING WHAT WAS EASIER FOR USERS, I WAS SAYING THAT FROM A POINT OF VIEW OF SECURITY USING A JAVASCRIPT TO INSERT CODE INTO A TEXTAREA OR ENTERING IT MANUALLY MAKES NO DIFFERENCE AS VALIDATION SHOULD BE HAPPENING SERVER-SIDE ANYWAY

FROM A POINT OF VIEW OF CONVENIENCE IT'S EASIER TO HIGHLIGHT AND CLICK, CERTAINLY

BTW TINYMCE HAS AN MS WORD INTERFACE IF YOUR USERS ARE FAMILIAR WITH THE PROGRAM

HTML is perfectly safe to allow as long as you restrict it to the equivalent tags that BBcode gets converted to.

The important ones to disallow are <script> <iframe> <object> etc which allow anything to be attached into the page.

restricting the tags is not enough - you need to restrict the attributes as well e.g. onclick.

once again htmlpurifier is what you need. http://htmlpurifier.org/

BECAUSE IT IS GENERALLY SAFER TO DISALLOW ALL HTML AND USE BBCODE TO MARK UP CONTENT (PLUS IT'S EASIER THAN MANAGING LIMITED HTML)

TINY MCE IS CLIENT-SIDE - IT WON'T STOP PEOPLE INPUTTING HTML INTO ITS TEXTAREA IF THEY WANT TO, INPUT VALIDATION --MUST-- BE DONE SERVER-SIDE. YOU COULD WRITE A JAVASCRIPT TO SEARCH THE TEXTAREA FOR HTML TAGS BEFORE IT'S SENT TO THE SERVER BUT THIS CAN BE BYPASSED. SERVER SIDE FILTERING WITH STRIP_TAGS OR WHATEVER IS ESSENTIAL

I WASN'T ARGUING WHAT WAS EASIER FOR USERS, I WAS SAYING THAT FROM A POINT OF VIEW OF SECURITY USING A JAVASCRIPT TO INSERT CODE INTO A TEXTAREA OR ENTERING IT MANUALLY MAKES NO DIFFERENCE AS VALIDATION SHOULD BE HAPPENING SERVER-SIDE ANYWAY

FROM A POINT OF VIEW OF CONVENIENCE IT'S EASIER TO HIGHLIGHT AND CLICK, CERTAINLY

BTW TINYMCE HAS AN MS WORD INTERFACE IF YOUR USERS ARE FAMILIAR WITH THE PROGRAM