# Limit\_rate dynamically using $arg - security

**URL:** <https://www.ruby-forum.com/t/limit-rate-dynamically-using-arg-security/218587>\
**Category:** NGINX\
**Created:** [April 4, 2012, 10:40pm UTC](https://www.ruby-forum.com/t/limit-rate-dynamically-using-arg-security/218587 "2012-04-04T22:40:20Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [April 4, 2012, 10:40pm UTC](https://www.ruby-forum.com/t/limit-rate-dynamically-using-arg-security/218587/1 "2012-04-04T22:40:20Z")

</div>

I’ve been looking for a way to limit videos to their bitrate to save  
bandwidth and I’ve come up with this code

```
        if ($arg_LIMITSPEED) {
          set $limit_rate $arg_LIMITSPEED;
        }

```

It works but I would like to know if this code would be secure to use on  
a production server.

I am not worried about users setting their LIMITSPEED high on their own  
because I am limiting speeds at the network level as well.

Posted at Nginx Forum:

> **[limit\_rate dynamically using $arg - security](https://forum.nginx.org/read.php?2,224950,224950#msg-224950)**
>
> I've been looking for a way to limit videos to their bitrate to save bandwidth and I've come up with this code if ($arg\_LIMITSPEED) { set $limit\_rate $arg\_LIMITSPEED; } It works but I would like to know if this code wo

---

<div class="post-metadata">

**Author:** ![shoshomiga](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ccd318/32.png) [@shoshomiga](https://www.ruby-forum.com/u/shoshomiga)\
**Post date:** [April 4, 2012, 11:33pm UTC](https://www.ruby-forum.com/t/limit-rate-dynamically-using-arg-security/218587/2 "2012-04-04T23:33:38Z")

</div>

On 4 April 2012 21:40, shoshomiga [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I am not worried about users setting their LIMITSPEED high on their own  
> because I am limiting speeds at the network level as well.

To be honest, I’m not sure what definition of “insecure” you could be  
thinking of that _isn’t_ “the user can override it trivially” 🙂

If you’re doing the rate limiting at the network level properly, then  
why duplicate the effort? It’s just one more place you have to change  
when you upgrade the speed limits.

Personally, I’m prototyping a streaming service at the moment using  
[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com · GitHub](http://wiki.nginx.org/X-accel#X-Accel-Limit-Rate) and a double  
proxy\_pass (via X-Accel-Redirect to an internal storage proxy\_pass).  
It all looks like it works nicely, and allows the dumb storage backend  
to throw data at the nginx router as fast as nginx accepts it, and for  
the first (intelligent) proxy\_pass backend to _decide_ the bitrate via  
X-Accel-Limit-Rate. I’ll blog it soonish 🙂

## Jonathan

Jonathan M.  
London, Oxford, UK

> **[Jonathan Matthews :: Words Typed, Great Rates For Cash](https://www.jpluscplusm.com)**

---

<div class="post-metadata">

**Author:** ![shoshomiga](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ccd318/32.png) [@shoshomiga](https://www.ruby-forum.com/u/shoshomiga)\
**Post date:** [April 5, 2012, 1:26pm UTC](https://www.ruby-forum.com/t/limit-rate-dynamically-using-arg-security/218587/3 "2012-04-05T13:26:30Z")

</div>

## Jonathan M. Wrote:

> > 
> 
> “insecure” you could be  
> the moment using  
> X-Accel-Limit-Rate. I’ll blog it soonish 🙂  
> [mailman.nginx.org archive](http://mailman.nginx.org/mailman/listinfo/nginx)  
> By security I meant vulnerability to buffer overflows and other exploits  
> since limit\_rate is probably not meant to recieve that kind of  
> unsanitized input.

Posted at Nginx Forum:  
[http://forum.nginx.org/read.php?2,224950,224967#msg-224967](http://forum.nginx.org/read.php?2,224950,224967#msg-224967)

---

<div class="post-metadata">

**Author:** ![shoshomiga](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ccd318/32.png) [@shoshomiga](https://www.ruby-forum.com/u/shoshomiga)\
**Post date:** [April 5, 2012, 4:44pm UTC](https://www.ruby-forum.com/t/limit-rate-dynamically-using-arg-security/218587/4 "2012-04-05T16:44:30Z")

</div>

Hello!

On Thu, Apr 05, 2012 at 07:26:06AM -0400, shoshomiga wrote:

> > $arg\_LIMITSPEED;
> > 
> > > ```
> > > }
> > > 
> > > ```
> > > 
> > > It works but I would like to know if this code  
> > > would be secure to use on  
> > > a production server.

[…]

> By security I meant vulnerability to buffer overflows and other exploits  
> since limit\_rate is probably not meant to recieve that kind of  
> unsanitized input.

It should be safe. Note though that it will log error if there  
are invalid values passed, which may in turn be used as a DoS  
vector.

To be on safe side, I would recommend sanitizing the input, e.g.  
with map{}. Something like this should work:

```
map $arg_speed $speed {
    default 64k;
    64k 64k;
    128k 128k;
    256k 256k;
}

...

set $limit_rate $speed;

```

Maxim D.

---

<div class="post-metadata">

**Author:** ![shoshomiga](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ccd318/32.png) [@shoshomiga](https://www.ruby-forum.com/u/shoshomiga)\
**Post date:** [April 5, 2012, 5:06pm UTC](https://www.ruby-forum.com/t/limit-rate-dynamically-using-arg-security/218587/5 "2012-04-05T17:06:52Z")

</div>

## Maxim D. Wrote:

> > > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> > > 
> > > > It works but I would like to know if this  
> > > > unsanitized input.
> 
> ```
> map $arg_speed $speed {
> default 64k;
> 64k 64k;
> 128k 128k;
> 256k 256k;
> }
> 
> ...
> 
> set $limit_rate $speed;
> 
> ```

Is there a way to typecast to int instead?

map{} won’t give me enough flexibility and it would probably be slower  
than a typecast.

Posted at Nginx Forum:  
[http://forum.nginx.org/read.php?2,224950,224974#msg-224974](http://forum.nginx.org/read.php?2,224950,224974#msg-224974)