On Fri, Mar 21, 2014 at 2:40 PM, Chris McMahon <[email protected]>wrote:

>
>
>
> On Fri, Mar 21, 2014 at 2:27 PM, Arthur Richards 
> <[email protected]>wrote:
>
>> (in prod, we at least used to use memcached to store session data, but
>> dunno if this is still the case or if this is the case for betalabs).
>> Anyways, there could be something wonky there causing token mismatch
>> problems. This seems somewhat unlikely to me because if this were a
>> problem, we would probably experience more issues on betalabs than we have
>> been - but it certainly still seems possible.
>>
>> Chris mentioned to me earlier that he pinged Coren about this on IRC -
>> any followup yet, Chris?
>>
>
> Yes, I talked with Coren and hashar both briefly.  We're using memcache in
> beta labs for session storage also.  Neither Coren nor hashar had any
> further illumination.
>

:-/ I dont know much about the under-the-hood aspect of this but is there
some way we can see what's going into and coming out of memcached while
replicating the problem? It would be nice to rule this out.


>
> So here's another question:
>
> This code is in MF:
>
>         private function submitSettingsForm() {
>                 $context = MobileContext::singleton();
>                 $request = $this->getRequest();
>
>                 if ( $request->getVal( 'token' ) !=
> $context->getMobileToken() )
>
> if the token in $request is always expected to be equal to the token in
> $context, then why does this if() statement even exist?  Why do this check
> in the first place? Whatever this is guarding against seems to be actually
> happening.
>

While the tokens are expected to be equal, they aren't always. Usually when
they aren't equal, it is for some benign reason, but it can be the result
of someone attempting to use the form as a cross site request forgery
vector (https://www.mediawiki.org/wiki/Cross-site_request_forgery).  Long
story short, we do this for security reasons - the approach here is very
common throughout mediawiki and a standard way to prevent CSRF attacks.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Reply via email to