On 10/3/11 10:58 PM, Mike Wacker wrote:
> On 10/3/2011 8:05 PM, Mike Wacker wrote:
>> I've checked a new provisional version of XEP-0045 into git...
>>
>> Latest diff:
>>
>> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7
>>
>> Diff from 1.24:
>>
>> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7
>>
>> Rendered version:
>>
>> http://xmpp.org/extensions/tmp/xep-0045-1.25.html
>>
>> Continued feedback would be appreciated.
>>
>> /psa
>>
>>
> Under 13.6, Denial of Service, we should also mention room creation.
> We've listed a lot of bad things that can be done in a room, but we've
> left out the room creation process itself.
> 
> For example, just like one could register a lot of nicks to deny use of
> them to others, one could also do the same with rooms if they send the
> initial presence stanza presence to create the room but don't configure
> it afterwards. We also say an implementation MAY set a timeout for
> initial configuration of a room once its created, but from a security
> point of view not setting a timeout could lead to resource starvation.
> 
> If the server never times out a room that is created but not configured
> and unlocked, then an easy DOS vector is to flood the server with room
> creation requests but never configure any of the rooms. Since these
> unconfigured rooms never time out, these creation requests will
> eventually starve the server of resources. Throttling won't work here,
> as it will slow but not stop the eventual starvation.
> 
> Two mitigations would be to either time-out unconfigured rooms or put a
> cap on the number of unconfigured rooms a single user can create. You
> could also have a max cap of total rooms for all users, but that also
> has DOS implications because even if malicious users can't DOS the
> server, they can DOS other users trying to create rooms if they can hit
> the server cap.

Good points. I'll incorporate those into the spec.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


Reply via email to