Что следует учитывать при разработке веб-страниц с помощью ASP. Друзья, использующие ASP, могут ознакомиться с этими шагами.
1. Никогда не верьте, что пользовательский ввод имеет соответствующий размер или содержит соответствующие символы. Пользовательский ввод всегда следует проверять, прежде чем использовать его для принятия решений. Лучший вариант — создать компонент COM+, который можно будет вызывать со страницы ASP для проверки ввода пользователя. Вы также можете использовать метод Server.HTMLEncode, метод Server.URLEncode или один из примеров кода внизу этой страницы.
2. Не создавайте строку подключения к базе данных на странице ASP путем объединения строки, введенной пользователем. Злоумышленники могут получить доступ к базе данных, вставив код во входные данные. Если вы используете базу данных SQL, используйте хранимую процедуру для создания строки подключения к базе данных.
3. Не используйте имя учетной записи администратора SQL по умолчанию sa. Каждый, кто использует SQL, знает, что учетная запись sa существует. Создайте еще одну учетную запись управления SQL с безопасным и надежным паролем и удалите учетную запись sa.
4. Прежде чем сохранять пароли пользователей клиентов, используйте алгоритм хеширования, кодировку Base64 или используйте Server.HTMLEncode или Server.URLEncode для кодирования этих паролей. Вы также можете использовать один из примеров кода внизу этой страницы, чтобы проверить символы в секрете клиента.
5. Не размещайте имена и пароли административных учетных записей в административных сценариях или страницах ASP.
6. Не принимайте решения в своем коде на основе заголовков запросов, так как данные заголовков могут быть подделаны злоумышленниками. Всегда кодируйте данные запроса перед их использованием или проверяйте содержащиеся в нем символы, используя приведенный ниже пример кода.
7. Не храните данные безопасности в файлах cookie и не скрывайте поля ввода на веб-страницах.
Всегда используйте Secure Sockets Layer (SSL) с приложениями на основе сеансов, чтобы избежать риска отправки файлов cookie сеанса без их шифрования. Если файл cookie сеанса не зашифрован, злоумышленник может использовать файл cookie сеанса в одном приложении для получения доступа к другому приложению в том же процессе.
8. При написании приложений, фильтров или объектов COM+ ISAPI помните о переполнении буфера из-за размера переменных и данных. Также помните о проблемах канонизации, которые могут возникнуть в результате интерпретации, например, интерпретация абсолютных путей как относительных путей или URL-адресов.
9. Когда приложение ASP, работающее в однопоточном подразделении (STA), переключается на многопоточное подразделение (MTA), токен олицетворения становится устаревшим. Это может привести к тому, что приложение запустится без олицетворения, что позволит ему эффективно работать с идентификатором процесса, который может разрешить доступ к другим ресурсам. Если вам необходимо переключить модели потоков, отключите и удалите приложение перед внесением изменений.
пример кода
Этот пример кода содержит функцию, которая удаляет потенциально опасные символы из строки, отправленной в функцию. В обоих приведенных выше примерах укажите кодовую страницу, чтобы обеспечить правильную кодировку. В следующем примере используется Microsoft Visual Basic® Scripting Edition (VBScript):
<%@ LANGUAGE=VBScript %> <% Ответ.Кодовая страница = 1252 Response.Write(Hello и RemoveBadCharacters(Request.Form(UserName))) Response.Write(<BR>Вот почему вы получили ошибку:) Функция RemoveBadCharacters(strTemp) Тусклое регулярное выражение Установить регулярное выражение = Новое регулярное выражение regEx.Pattern = [^/s/w] regEx.Global = Истина RemoveBadCharacters = regEx.Replace(strTemp, ) Конечная функция %> |
В следующем примере используется Microsoft JScript®:
<%@ LANGUAGE=JScript %> <% Ответ.Кодовая страница = 1252; Response.Write(Привет, + RemoveBadCharacters(Request.Form(Имя пользователя))); Response.Write(<BR>Вот почему вы получили ошибку:); функция RemoveBadCharacters(strTemp) { strTemp = strTemp.replace(/[^/s/w]/g,); вернуть стрТемп; } %> |