1

EDIT

This question is related to compliance to a specific security test, the problem has nothing to do with Freemember extension. For the record : The solution found to pass the test was to simply str_replace the posted data to remove anything between < > before it's sent to the database.

Security test flags : Cross-Site Scripting: Persistent on freemember:update_profile form

The test machine manages to insert javascript code in the form fields

Any ideas ?

Improve this question
0

I would assume that freemember is either pulling in values from the form using the unclean $_POST array or using ee()->input->post('var_name'); (note the lack of second security parameter which should be true). I suspect the former as using the EE function (on latest 2.10.1) I beleive still strips dangerous script tags regardless of the XSS_Clean parameter.

Because of the lack of detail here I can only surmise, however I would take a look through the modules code, identify where it gets the posted values and change the method of retrieval to 

ee()->input->post('var_name', true);

This should then parse and clean the posts.

Another alternative is that you've changede the XSS Cleaning setting (in Admin > Security) to no or off. Please review this setting.

If I where you I'd submit this as a bug on freemember if your security settings are correct but it's still defeating them, the module is by DevDemon so you can submit an issue here

Lastly, you have set an encryption key on freemember, right?? Docs

Improve this answer
5
  • I see nothing suspicious in freemember, it uses the secure parameter. The secure forms parameter in Admin > Security has been removed and forms are now secure by default. Yes, I use an encryption key. I've submitted an issue on devdemon's GitHub.
    – laurent
    May 26 '15 at 5:09
  • HI laurent, ok so much for the 'usual suspects' then! What type of field is it that is letting script through? Also I don't suppose you can share the attack vector used that exposed the weakness? I'm wondering if there's a potentual issue within a 3rd party fieldtype...
    – Blatant
    May 26 '15 at 8:33
  • Alas, I have no 'special fieldtype', the script is passed through a custom field firstname it is a simple input field...
    – laurent
    May 26 '15 at 9:24
  • I know this is old, but github.com/devdemon/freemember/issues/85 suggests a fix for this
    – WOUNDEDStevenJones
    Mar 2 '17 at 18:37
  • The bugfix quoted by WOUNDEDStevenJones looks quite correct to me! Indeed this is where I was leading to when I said to scan the source and look for where it handles the inputs. The form on the bugfix is essentually the same deal with up to date EE3 style code (perhaps EE2.2+ even as its using the ee() super), instead of setting XXS Clean on the call to post(), call it explicitly, where it didnt before.... Thanks for the link :)
    – Blatant
    Mar 6 '17 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.