Na co dzień nie zajmuje się bezpieczeństwem, chociaż jak widać po wpisach na blogu skręcam coraz bardziej w ta stronę :) W każdym razie dzisiaj podzielę się ciekawym błędem, który przypadkiem udało się znaleźć na stronie logowania jednej z w miarę znanych firm.
Zaczęło się od tego, że ktoś przeskanował stronę szukając podatności typu SQLInjection. Ponieważ aplikacja posiada zabezpieczenia, fakt ten został wykryty. Natomiast co zwróciło moja uwagę, że dla niektórych zapytań, pomimo tego że zabezpieczenie zadziałało, aplikacja zwróciła poprawnie stronę (status 200). Po odpytaniu strony w ten sam sposób, dało się zauważyć że zawiera część zapytania które miało wykonać SQLInjection.
Testowany przez atakującego parametr bckg w url nie był wykorzystywany do wykonywania zapytań w bazie a jedynie do wygenerowania kilku linków na stronie. Tak, więc pomimo wykrycia ataku aplikacja działała normalnie, stwierdzając najwyraźniej że nie stanowi to dla niej zagrożenia. Wykrywając próbę wykonania SQLInjection pomijała przy okazji część kodu odpowiedzialnego za ochronę przez XSS. Poniżej payload jakim udowodniłem istnienie luki:
select
"
onmouseover="document.getElementById('loginButton').onclick=function() {alert(document.getElementById('j_password').value)}"
Co po zakodowaniu daje:
http://..../login.html?bckg=%0Aselect%0A%22%0A%0Aonmouseover=%22document.getElementById('loginButton').onclick=function()%20%7Balert(document.getElementById('j_password').value)%7D%22%0A
Jak widać nic specjalnie wyszukanego, jedynie w pierwszej części symulujemy próbę ataku SQLInjection, poprzez umieszczenie "select".
Morał z tej opowiastki jest taki, że w tym wypadku dobrze zabezpieczona aplikacja poległa w momencie gdy najpierw został symulowany atak innego rodzaju. Można powiedzieć, że w systemie bezpieczeństwa nastąpił "desync" :)