Я уже несколько дней читаю об уязвимостях CSRF и XSS и пытаюсь найти решение, которое 1) легко внедряется и используется, 2) использует Javascript для выполнения большой работы, и 3) делает практически невозможной атаку CSRF против.
Я не видел решения, подобного тому, которое я собираюсь описать.Надеюсь, это не значит, что он протекает.
Я нашел следующее решение, основанное на моих знаниях AJAX и JS.В этом коде предполагается, что пользователь прошел через экран входа в систему, и переменная сеанса была установлена на сервере и в файле cookie с теми же значениями.
Проще вставить код и задокументировать его, чем объяснять, что он делает.Этот код будет запускаться на странице, которую пользователь видит сразу после входа в систему:
<script>
// this is the constructor:
function Controller(){
//the following 2 variables are private, and inaccessible via JS calls
var secretToken; //this holds the session token, but cannot be read by the browser
//returns the session token from the server
var x = new ajaxObject('AJAX/retrieve_session_cookie.lasso');
x.callback = function(responseText, responseStatus){
secretToken = responseText;
}
//this is a private function, again inaccessible via JS calls
function getCookie(){
x.update();
}
//the following 2 functions are publicly accessible
//just a test function to ensure that secretToken is invisible
this.tell = function(){
alert(secretToken);
}
//privileged function that calls a private function, to load the token into a private variable
this.initialize = function(){
getCookie();
}
}
E = new Controller();
E.initialize();
</script>
Переменная secretToken не может быть прочитана пользователем, так как она является закрытой переменной-членом объекта контроллера.
В retrieve_session_cookie.lasso я проверяю допустимый сеанс и сопоставляю переменную сеанса с cookie браузера.Если оба эти условия выполнены, переменная сеанса возвращается в виде простого текста, где она установлена как secretToken в объекте E.Повторно проверив, чтобы увидеть, соответствует ли cookie токену сеанса, я надеюсь, что получить токен сеанса через CSRF будет невозможно, поскольку он не может подделать cookie.Ввод 'AJAX / retrieve_session_cookie.lasso' ничего не даст, если он не был введен пользователем во время действительного сеанса и только с компьютера пользователя.
Кроме того, теперь мой контроллер имеет локальный доступ ктокен сеанса, я мог бы «записать» токен сеанса при каждом запросе AJAX, поэтому мне даже не нужно думать о том, чтобы он передавал токен каждый раз, когда запрашивается файл AJAX.Все объекты и запросы AJAX будут инициализированы как частные члены в конструкторе объекта контроллера, поэтому никто не сможет получить доступ / изменить функции обратного вызова для раскрытия токена сеанса.
Передача токена сеанса с каждым вызовом AJAX защитит все остальные файлы AJAX, так как все они будут выполнять одинаковую проверку для cookie, соответствующего токену сеанса, перед возвратом каких-либо данных.И в моем программировании было бы на одну переменную меньше беспокоиться.
Если бы я продвинулся с контроллером, реализованным таким образом, был бы ЛЮБОЙ способ доступа к токену или его использования, либопользователем или злоумышленником через CSRF?