414 URI too long. But not always

Question

I have the following url to reset my password:

http://example.com/resetPassword/LtoyURJd5AYuP3KEGg4gx8fvUprT37LBQDlvhg22qjg=.eyJ0b2tlbiI6IiQyeSQxMCRMTlgzU29HdEdOaExsay5yQ1puQ2ZlZ1wvbVNcL09BMDV2SjhcL1wvcHNRNjZaQmRpbWpOdnhGQlciLCJ0aW1lIjoiMjAxNS0xMi0xMVQwOTozOToyOSswMTAwIiwiZW1haWwiOiJsb3JlbS51dC5hbGlxdWFtQGZldWdpYXRwbGFjZXJhdHZlbGl0Lm9yZyJ9

On the local development machine it works without any problems. But on the public server (hosted on amazon ec2) i get a 414 Uri to long. I have tried to fix it but i can't seem to solve the issue. ps: i have replaced the url to example.com

I have tried adding the following line to /etc/apache2/apache2.conf, the vhosts conf. Both at the same time and seperate. And yes. I also restarted apache service every time.

LimitRequestLine 8190

Also when i request other long url's there is no problem. For example. i renamed robots.txt so i could request the following urls:

http://example.com/robotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsr/robotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsroborobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobots.txtrobots.txtrobots.txtrobots.txtrobots.txtrobots.txtrobots.php?test=ok
http://example.com/robotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsr/robotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsroborobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobotsrobots.txtrobots.txtrobots.txtrobots.txtrobots.txtrobots.txtrobots.php
http://example.com/robots.txt?klsadjflkasdjflkdsajflkdsja=sdakjflksadjfoaiwsefnalkfjsdakjflksadjfoaiwsefnalkfjsdakjflksadjfoaiwsefnalkfjsdakjflksadjfoaiwsefnalkfjsdakjflksadjfoaiwsefnalkfjsdakjflksadjfoaiwsefnalkfjsdakjflksadjfoaiwsefnalkfj

I also moved robots.txt to a other location and made a rewrite rule for it. Even then it seems to work correct. So mod_rewrite does not seme to be the problem.

The problem occurs when the url becomes longer as +/- 275 chars. It worked with a reset link of 273 and the longer was 324 chars. The robots long url was arround 400 chars i think.

I also seem to have the problem (which i am not shure is related or not) that my vhosts is not loaded correctly. The server always redirects to the path defined in the default. Not of the vhosts. apache2ctl -s output gives the following:

ubuntu@ip-172-31-28-19:~$ apache2ctl -S                                                                                                                                                                                                                                                               
VirtualHost configuration:
<ip>:80        example.com (/etc/apache2/apache2.conf:228)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/public"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex proxy: using_defaults
Mutex default: dir="/var/lock/apache2" mechanism=fcntl 
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33 not_used
Group: name="www-data" id=33 not_used

---

Update 2015-12-18 In discussion with the other developers in my team we will be choosing a different base image for this server on amazon. There seemed to be more problems than this. So this question has become obsolete.

Answer 1

Instead of base64_encode()ing the information you need to reset a password, with all the information there for everyone to base64_decode() it, see this:

// this is from your example
$encoded = 'eyJ0b2tlbiI6IiQyeSQxMCRMTlgzU29HdEdOaExsay5yQ1puQ2ZlZ1wvbVNcL09BMDV2SjhcL1wvcHNRNjZaQmRpbWpOdnhGQlciLCJ0aW1lIjoiMjAxNS0xMi0xMVQwOTozOToyOSswMTAwIiwiZW1haWwiOiJsb3JlbS51dC5hbGlxdWFtQGZldWdpYXRwbGFjZXJhdHZlbGl0Lm9yZyJ9';

$data = json_decode(
    base64_decode($encoded), 
    true
);

// array (
//     'token' => '$2y$10$LNX3SoGtGNhLlk.rCZnCfeg/mS/OA05vJ8//psQ66ZBdimjNvxFBW',
//     'time' => '2015-12-11T09:39:29+0100',
//     'email' => '[email protected]',
// )

Persist data in a table

How about instead persisting that data - either in a database or elsewhere with limited lifetime - and then either using a UUID or a hash created with that data above as an identifier for the password reset?

CREATE TABLE `password_reset` (
  `id` char(40) NOT NULL DEFAULT '',
  `token` char(60) NOT NULL DEFAULT '',
  `time` datetime NOT NULL,
  `email` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Identifier from SHA-1

Then generate your identifier:

$id = sha1(serialize([
    'token' => '$2y$10$LNX3SoGtGNhLlk.rCZnCfeg/mS/OA05vJ8//psQ66ZBdimjNvxFBW',
    'time' => '2015-12-11T09:39:29+0100',
    'email' => '[email protected]',
    'foo' => microtime(), // for some variation
]);

Store the data in your table, and there your have your fixed length identifier, and your password reset URL becomes

http://example.com/resetPassword/0f4d2541c25ba8edbb3cd6df362d7dbf6317d7a5

Identifier as UUID

Instead of using sha1() to create a hash from some input, it would probably be better to use, for example, ramsey/uuid to generate a time-based UUID (fixed length, 36 characters):

use Ramsey\Uuid\Uuid;

$id = Uuid::uuid1()->toString()

While this doesn't solve your problem of allowing really long URIs, it solves the problem in a better, much safer way.

Bonus

Have a look at OWASP's Forgot Password Cheatsheet and related, maybe it helps in making your application more secure!

Answer 2

Use POST method instead of get and it will resolve your problem.

But if you still would like to use "GET" method instead of "POST" method, then under Apache, value of LimitRequestLine can be changed to something larger than its default of 8190 if you want to support a longer request URI.

If you can't find LimitRequestLine into apache config file, just add the line yourself anywhere you like. e.g: LimitRequestLine 100000

However, note that if you're actually running into this limit, you are probably abusing GET to begin with. You should use POST to transmit this sort of data -- especially since you even concede that you're using it to update values