I’ve been reading the interesting blog post about the recent CVEs related to SPIP:
It seems one attack vector is through _hidden fields in forms. According to what I read in the blog post, _some_val should never be a field name that’s submitted from the front end. Such fields are eval()uated and <?php tags within those variables would be executed.
Would this be something ecran_securite could take care of?
I think this would work without affecting any users:
POST/GET variables starting with « _ » should be sanitized.
This would be more extreme, but I think it’s justified:
POST starting with _ should be removed
Log to spip.log saying "fields starting with _ are reserved for backend code and should never be submitted by user).
Second about #ENV** or other #BALISES**, here I don’t have an idea. Just never use it
Do you have an opinion on _hidden?
I would be willing to work on a patch for ecran_securite or elsewhere, but I am probably missing something!
The main reason is that if as devs we should never use _some_val as name of an input element, we should log to spip.log and block this. To prevent people building such fields into plugins in the future.
would have make no difference on any of the CVE from the post. No _some_var was posted, but the plugins were populating the _ hidden key with unsafe html content coming from other variables posted and not sanitized
OK.
Would it be a good idea to remove or sanitize _hidden input from frontend for forms? As I understand this should never happen. It should only be used in the CVT functions, not the formulaire.html. So it would never come in.
_hidden is not a thing posted, it is just a conventionnal key for the return of charger() to insert hidden inputs (but in fact any html) in the form.
Have a detailled look to the CVE, you’ll se the issues are totaly unrelated to any _var, but to normal posted values used by php code without any sanitization and inserted in this _hidden key wich is not automatically sanitized by SPIP to allow some html insertion.
