1. Принцип атаки
Файлы cookie в основном используют небезопасную практику хранения информации о входе в пользу пользователя в файлах cookie в текущей сети.
Мы знаем, что пользовательская система на основе общих файлов cookie будет хранить как минимум две переменные в файлах cookie: имя пользователя и пользователь, где имя пользователя является именем пользователя, а пользовательский уровень-пользовательский уровень. Когда наш браузер обратится к странице ASP, он излучит что -то вроде
Get /.../file.asp http 1.0
...
Куки: username = user & userlevel = 1
...
Затем, пока мы знаем имени пользователя и пользовательских значений администратора (при условии администратора и 5 соответственно), мы можем перенести его
Get /.../file.asp http 1.0
...
Куки: username = Admin & UserLevel = 5
...
Чтобы получить разрешения администратора. Очень просто, верно? Однако до того, как была обнаружена уязвимость, почти все системы управления пользователями опирались на файлы cookie.
2. Безопасно хранить информацию пользователя
Поскольку файлы cookie небезопасны, и мы должны хранить информацию о входе в систему пользователей, где их следует хранить?
Мы заметили, что в ASP, помимо файлов cookie, есть также сеанс, который может хранить информацию. Сеанс хранится на сервере и не может быть изменен клиентом по желанию, поэтому он имеет чрезвычайно высокую безопасность. Таким образом, каждый может изменить код всех файлов cookie на сеанс.
3. Храните информацию пользователя в течение длительного времени
Сеанс используется для сохранения информации о входе в систему. Метод, описанный в этом разделе.
Есть два варианта этого метода. Предоставьте его в соответствии с файлами cookie. Код для реализации этого метода выглядит следующим образом:
VBS:
<%
DIM USERNAME, пароль
Имя пользователя = сеанс (имя пользователя)
Если имя пользователя = тогда
'В сеансе нет информации о входе в систему
username = request.cookies (имя пользователя)
пароль = request.cookies (пароль)
«Обратите внимание на имя пользователя и пароль, полученные в двух вышеуказанных предложениях, чтобы предотвратить уязвимости в инъекциях SQL (т.е. отфильтровать отдельные кавычки»), опущены здесь
Если username = или пароль = тогда
'Пользователь не вошел в систему
...
еще
'Здесь предполагается, что объекты Conn и RS были созданы
Rs.Open выберите Top 1 * из [пользователя], где username = '& username &' and password = '& password &', conn, 1, 3
Если rs.eof тогда
'Информация в файлах cookie является незаконной
...
еще
'Информация в файлах cookie является законной и автоматически вошла в систему
Session (имя пользователя) = имя пользователя
...
конец, если
конец, если
еще
'Информация пользователя уже существует в сеансе и читается напрямую
...
конец, если
%>
JS:
<%
var username, пароль;
Имя пользователя = сеанс (имя пользователя) +;
if (username == || username == не определен) {
// В сеансе нет информации пользователя
username = request.cookies (имя пользователя) +;
пароль = request.cookies (пароль) +;
// Обратите внимание на имя пользователя и пароль, полученные в двух вышеупомянутых предложениях, чтобы предотвратить уязвимости SQL -инъекции (т.е. отфильтровать отдельные кавычки), опущены здесь
if (username == || username == undefined || пароль == || пароль == не определен) {
// пользователь не вошел в систему
...
}
еще {
// здесь предполагается, что объекты Conn и RS были созданы
rs.open (выберите Top 1 * из [пользователя], где username = ' + username +' и password = ' + password +', conn, 1, 3);
if (rs.eof) {
// информация в файлах cookie является незаконной
...
}
еще {
// информация в файлах cookie является законной и автоматически вошла в систему
Session (имя пользователя) = имя пользователя +;
...
}
}
}
еще {
// Информация пользователя уже существует в сеансе и читается напрямую
...
}
%>
Тем не менее, этот метод не очень безопасен для пользователей, потому что браузер будет передавать файлы cookie каждый раз, когда он посещает страницу, а учетная запись пользователя будет украдена после того, как файлы cookie, содержащие пароль, будут получены другими. Для этого случая появляется второй метод, то есть добавьте код проверки поля в базу данных информации пользователя. Значение кода добавлено. При проверке пользовательской информации в файлах cookie проверяются только имя пользователя и VerifyCode. Преимущество этого метода состоит в том, что даже если файлы cookie пользователя получают хакер, он может использовать только этот временный код Verification для входа в систему и не может получить пароль пользователя. Пока этот пользователь снова входит в систему с именем пользователя и паролем, значение VerificationCode изменится, и хакер не сможет войти через исходный код Verification.
Реализация этого метода требует лишь небольших изменений в коде метода, упомянутого выше. Во -первых, в вашей программе входа вам нужно добавить абзац, в котором проверка проходит для хранения информации пользователя:
VBS:
<%
Response.cookies (verifycode) = int (rnd * 2100000000)
%>
JS:
<%
Response.cookies (verifycode) = math.floor (math.random () * 2100000000);
%>
Затем, в приведенном выше коде проверки, измените проверку файлов cookie (пароль) на проверку файлов cookie (VerifyCode).
4. Заключение
Благодаря нашему анализу и обработке, уязвимость, подходящие для файлов cookie, была полностью разрешена, и с тех пор наши программы ASP стали более безопасными.
2007-08-05 20:37 Начинается письмо
2007-08-05 21:14 Первое издание завершено