let's get rid of {S_FORM_TOKEN}

Discussion of general topics related to the new version and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
Forum rules
Discussion of general topics related to the new release and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
Post Reply
code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

let's get rid of {S_FORM_TOKEN}

Post by code reader »

as one of the security measures resulted from the security audit, a new token was added: S_FORM_TOKEN.
iiuc, in principle, this token is supposed to appear in each and every form in the template (.html) file.
this does not make sense: if this token should appear in every form, the right place to implement it is in the template engine.
just have the template engine replace the </form> tag with the content of S_FORM_TOKEN, followed by </form>.

i thought so from the first time i saw this new token, but did not say anything because the probability that the dev team would even consider such a suggestion was very remote in the hectic days after the audit, with all the pressure to get to gold and the myriad of changes the audit created.

however, now, that 3.0 was branched, it makes perfect sense to correct the situation on the main development trunk.
of course, to make it as painless as possible, the template engine should still parse the {S_FORM_TOKEN}, replacing it with nothing, so the fix won't break existing templates.
statm1
Registered User
Posts: 43
Joined: Thu Jul 21, 2005 7:58 am

Re: let's get rid of {S_FORM_TOKEN}

Post by statm1 »

Well, I dont think its such a good idea to let it automatically replace </form> with the token code. The html that {S_FORM_TOKEN} produces needs to be within a block level element if the author wants to remain standards compliant and if the author chooses to use XHTML Strict as is true with proSilver. If you used a subsilver based style and the DOCTYPE wasn't changed then it doesn't really matter. Plus it would restrict how the author codes his style. Inline tags are always more flexable than being hard-coded.
Marshalrusty
Project Manager
Project Manager
Posts: 272
Joined: Thu Oct 27, 2005 1:45 am

Re: let's get rid of {S_FORM_TOKEN}

Post by Marshalrusty »

code reader wrote:if this token should appear in every form, the right place to implement it is in the template engine.
just have the template engine replace the </form> tag with the content of S_FORM_TOKEN, followed by </form>.
But it doesn't appear in every form, and it shouldn't appear in every form.
User avatar
Kellanved
Former Team Member
Posts: 407
Joined: Sun Jul 30, 2006 4:59 pm
Location: Berlin

Re: let's get rid of {S_FORM_TOKEN}

Post by Kellanved »

It only applies for forms which do not use the confirm_box. The only clean solution would be using the form action, but that would leak the token via the referrer, so it can't be done without switching to db-based single-use tokens. It's something we consider, but it would be even more restrictive for the users and forbid things like clicking "back" after running into an error.

The template engine doesn't abstract over forms, so it isn't cleanly possible to just filter out the forms that need such a token. Also, as pointed out above, it would be very hard to create valid XHTML.

We are considering a design which would add form-level abstraction to the API, which could automagically take care of things like tokens and possibly AJAX, but that's still just a very early design sketch.

A step in-between would be a standarized hidden fields/form token template variable. That's something almost certain for 3.2.
No support via PM.
Trust me, I'm a doctor.
code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: let's get rid of {S_FORM_TOKEN}

Post by code reader »

Kellanved wrote:It only applies for forms which do not use the confirm_box. The only clean solution would be using the form action, but that would leak the token via the referrer, so it can't be done without switching to db-based single-use tokens. It's something we consider, but it would be even more restrictive for the users and forbid things like clicking "back" after running into an error.
i may be in complete misunderstanding here, but let me try anyway:
iiuc, there is absolutely no harm in including the "token" even in forms that do not need them.
the </form> tag is always "</form>". there are no attributes, or any other variation.
using the template engine to replace </form> with something else is quite "clean", and the gain of getting rid of all the {S_FORM_TOKEN} in all the template files is meaningful.

think about the whole "templating" thing: the idea is to separate presentation from application logic (often referred to as "business logic"). the "form token" has nothing to do with the presentation, and has no place in the presentation .html files.
sometimes you have to put stuff where it doesn't "really" belong because of constraints, or practicality considerations.
this is not one of those times. it is more practical, clean, and convenient to place the security-enhancement attribute outside the presentation and back in the logic piece of the puzzle. you will have this thing buried in one place, not bothering anyone, rather than what you have now, which is this {S_FORM_TOKEN} sprayed like some grafitty all over the place with no apparent function, beauty or form.
User avatar
DavidMJ
Registered User
Posts: 932
Joined: Thu Jun 16, 2005 1:14 am
Location: Great Neck, NY

Re: let's get rid of {S_FORM_TOKEN}

Post by DavidMJ »

In the end, functionality wins. Without an alternative implemented here and now, {S_FORM_TOKEN} is here to stay...
Freedom from fear
JRSweets
Registered User
Posts: 14
Joined: Tue Oct 12, 2004 4:48 pm
Contact:

Re: let's get rid of {S_FORM_TOKEN}

Post by JRSweets »

Does this token need to appear on all forms except when using the confirm_box function, or only forms that do not modify the database? It doesn't appear on the jumpbox, forum/topic sort/filter forms or the quick search box in viewforum/viewtopic.
User avatar
Highway of Life
Registered User
Posts: 1399
Joined: Tue Feb 08, 2005 10:18 pm
Location: I'd love to change the World, but they won't give me the Source Code
Contact:

Re: let's get rid of {S_FORM_TOKEN}

Post by Highway of Life »

DavidMJ wrote:In the end, functionality wins. Without an alternative implemented here and now, {S_FORM_TOKEN} is here to stay...
Hey David and Henry, just a thought; what are the reasons for using S_FORM_TOKEN instead of putting it in the S_HIDDEN_FIELDS var?
Image
User avatar
Acyd Burn
Posts: 1838
Joined: Tue Oct 08, 2002 5:18 pm
Location: Behind You
Contact:

Re: let's get rid of {S_FORM_TOKEN}

Post by Acyd Burn »

Highway of Life wrote:
DavidMJ wrote:In the end, functionality wins. Without an alternative implemented here and now, {S_FORM_TOKEN} is here to stay...
Hey David and Henry, just a thought; what are the reasons for using S_FORM_TOKEN instead of putting it in the S_HIDDEN_FIELDS var?
Far easier codewise with one function handling the form token instead of having to modify every instance of hidden fields (also those forms not having hidden fields).

Image
Post Reply