SF form injection vs security

[mwjames]

Creating a user (together with the verification of the input data during the signup) can be highly sensitive and be under special scrutiny for security (email, personal data etc.).

Currently $sfgFormPrinter->formHTML is used the fetch the html generated form definition and the question arises whether this creates a security risk by injecting a form before the data input without verification (false data, stale data etc.).

        list ( $form_text, $javascript_text, $data_text, $form_page_title, $generated_page_name ) =
            $sfgFormPrinter->formHTML( $form_definition, false, false );

Questions

• Is it OK to allow fields with the property uploadable (or whatever it is called in SF) during a registration process (where a file could contain malicious code)?
• Is it possible to hijack (via jquery/php from the outside) the form before it is presented to a user on the signup view?
• Any other question that could potentially be raised with respect to above topic?

@kghbln @toniher @JeroenDeDauw I don't have any answers but I'm looking for some insides whether this can be a real issue or not. In case it is an issue we should at least inform the user base about the potential.

PS: Looking at code samples like below makes me feel uneasy.

        list ( $form_text, $javascript_text, $data_text, $form_page_title, $generated_page_name ) =
            $sfgFormPrinter->formHTML( $form_definition, false, false );

        /* Run hook allow externals to modify output of form */
        wfRunHooks('SemanticSignupPrintForm', array( &$form_text, &$javascript_text, &$data_text, &$form_page_title, &$generated_page_name ) );

        $text = <<<END
                <form name="createbox" id="sfForm" onsubmit="return validate_all()" action="" method="post" class="createbox">
END;
        $text .= $form_text . '</form>';

        $wgOut->addMeta( 'robots', 'noindex,nofollow' );
        $wgOut->addHTML( $text );

[JeroenDeDauw]

What does this extension use SF for? I thought it stored semantic data, though guess it just stuffs things into a template. If it's just building a template, SF is not needed. I'm guessing the SF form input things are used, and that people can define the registration form using those?

[mwjames]

What does this extension use SF for?

It is just to generate a form and return a template transclusion which maybe better served by just trying to read the template first, generate the fields by adding the appropriate input field definitions without the potential hazard that can be added through some of the SF options.

[mwjames]

Maybe one could assign any page (no need forSF_FORM) to $egSemanticSignupSettings['formName'] that contains a #signupfields parser. #signupfields already generates the standard fields (user name, email using UserFieldsCreateTemplate) therefore extending the parser function could be an option to allow something like:

{{#signupfields:
    |field=Group;input;20
    |field=About me;text;20
    |template=UserSignup
}}

This would isolate html generation to one single source and would allow for strict control of what is being invoked as field before and after the content generation.

[toniher]

No doubt that the way is presently coded is not very orthodox and it might be potentially risky.
On the other hand, I do think that using SF is a positive point for the extension, so signup forms can use many existing SF features (e. g. values from category).

[kghbln]

About files: MW natively checks for the file extension as well as for the mime type, so I believe that there are no worries here.

About SF: + per @toniher

[mwjames]

I have no objections to above comments and just wanted to ensure that at least the question have been raised to avoid any potential issue.