id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
6751	django.contrib.auth.views.login can leak session	Yuanchen Zhu	nobody	"Suppose django.contrib.auth.views.login is configured at a certain url, say www.test.com/login.

Now if a client visits www.test.com/login (using GET) for the first time, ""login"" calls ""set_test_cookie"", and a session database record will be created. Suppose the client has cookie disabled, and it visits www.test.com/login again using GET, a differnt session database record will be created to store the test cookie. This process can go on and the session database will be filled with records containing single test cookies, allowing a DoS attack on the database.

I found this problem when I used the apache benchmark tool ""ab"" to benchmark the login page of my website. After making 10000 requests using ""ab"" three times in a row, I was really surprised that the session database now contains 30000 records, each only contains a single test cookie. This is done locally so these 30000 requests finish in < 5 minutes. Thus I imagine that someone with enough network bandwidth can force the creation of >3 million records in the session database of some django powered site in an hour.

I think the best way to fix the problem is to change the implementation of set_test_cookie so that no record is created in the database session. For example, it can just set a cookie based on some hash of the source ip of the request. Later on, can just test if the cookie is returned in a second request using only the source ip of the request. 

I am kind of new to web programming, so can people comment on if this is indeed a valid problem/solution, before I try to write a patch.
"		closed	contrib.sessions	dev		invalid	auth login set_test_cookie session leak	Jacob	Unreviewed	0	0	0	0	0	0