Говоря о кодировании URL-адресов, вы можете вспомнить об уязвимости кодирования URL-адресов, случившейся несколько лет назад. Жаль, что я родился не в то время. Когда я познакомился с Интернетом, лазейка уже давно исчезла.
Подробнее: что такое кодирование URL? Взгляните на определение, которое я скопировал из Интернета:
Цитата: Кодировка URL — это формат, используемый браузерами для упаковки ввода формы. Браузер получает все имена и значения из формы и отправляет их на сервер как часть URL-адреса или отдельно, используя кодировку параметра имя/значение (удаление непередаваемых символов, сортировка данных и т. д.). В любом случае формат ввода формы на стороне сервера выглядит следующим образом:
theName=Ichabod+Crane&gender=male&status=missing&headless=yes
Кодирование URL следует следующим правилам: Каждая пара имя/значение разделяется амперсандом; происходит из формы, разделенной символами =. Если пользователь не вводит значение имени, имя все равно будет отображаться, но без значения. Любые специальные символы (то есть те, которые не являются простыми семибитными символами ASCII, например китайские символы) будут закодированы в шестнадцатеричном формате с помощью знака процента %, включая, конечно же, специальные символы, такие как =, & и %.
Ха-ха, вы понимаете, на самом деле кодировка URL — это шестнадцатеричный ASCII-код символа. Однако есть небольшое изменение: вам нужно добавить «%» впереди. Например, "", его ASCII-код — 92, а шестнадцатеричное значение 92 — 5c, поэтому кодировка URL-адреса "" — . А как насчет URL-кодировки китайских иероглифов? Это очень просто, посмотрите на пример: ascii-код «Hu» — -17670, шестнадцатеричный — BAFA, а кодировка URL — «%BA%FA». Ха-ха, ты знаешь, как это преобразовать.
Обычно мы не используем кодировку URL-адреса, поскольку IE автоматически преобразует нецифровые буквы, которые вы вводите в адресную строку, в кодировку URL-адреса. Таким образом, для браузера http://blog.csdn.net/l%61ke2 эквивалентен http://blog.csdn.net/lake2 (обратите внимание, что я заменил a на %61 в первом URL-адресе). Ха-ха, возможно, вы помните, что кто-то предлагал добавить «#» в имя базы данных, чтобы предотвратить ее загрузку, потому что IE будет игнорировать следующие буквы при обнаружении #. Способ взлома очень простой — замените # на кодировку URL #. Первоначально я пытался использовать кодировку URL-адресов, чтобы избежать проверок внедрения, но это не удалось, поскольку сервер преобразовывал кодировку URL-адреса в символы.
Подождите, я, кажется, не по теме, хаха, извините :)
SQL-инъекция сейчас очень популярна, поэтому некоторые люди написали несколько антиинъекционных скриптов. Конечно, идеи разные, и результаты очень разные. Уважаемые читатели, пожалуйста, взгляните на часть кода универсальной версии asp с защитой от инъекций ××SQL ниже.
Fy_Url=Request.ServerVariables("QUERY_STRING")
Fy_a=split(Fy_Url,"&")
восстановить Fy_Cs(ubound(Fy_a))
При ошибке Возобновить Далее
от Fy_x=0 до ubound(Fy_a)
Fy_Cs(Fy_x) = влево(Fy_a(Fy_x),instr(Fy_a(Fy_x),"=")-1)
Следующий
От Fy_x=0 до ubound(Fy_Cs)
Если Fy_Cs(Fy_x)<>"" Тогда
Если Instr(LCase(Request(Fy_Cs(Fy_x))),"and")<>0, то
Ответ. Напишите «Произошла ошибка!»
Ответ.Конец
Конец, если
Конец, если
Следующий
Идея состоит в том, чтобы сначала получить отправленные данные, использовать «&» в качестве разграничения для получения и обработки группы имя/значение, а затем определить, содержит ли значение определенные ключевые слова (для простоты я оставляю только «и»). Если да, то это инъекция.
На первый взгляд значение проверено и проблем вроде бы нет. Хаха, да, со значением проблем нет, а как насчет имени?
Его значение группы имя/значение берется из Request.ServerVariables("QUERY_STRING"), хаха, извините, здесь что-то пошло не так. Request.ServerVariables("QUERY_STRING") предназначен для получения строки, отправленной клиентом. Кодировка URL-адреса здесь не будет автоматически преобразована. Ха-ха, если мы URL-адрес закодируем имя, а затем отправим его, ха-ха, тогда проверку можно обойти. Например, если параметр равен ph4nt0m=lake2 и lis0, программа может обнаружить его в этот момент, если вы отправите %50h4nt0m=lake2 и lis0 (кодировка URL-адреса p), программа оценит значение %50h4nt0m и %50h4nt0m; будет преобразовано в ph4nt0m , поэтому значение %50h4nt0m пусто, что позволяет обойти обнаружение.
Подождите, а почему проверку можно обойти, если имя не расшифровано, а значение обойти нельзя? Поскольку значение value берется из Request(Fy_Cs(Fy_x)), сервер его декодирует.
Как можно улучшить программу? Если вы можете получить декодированные данные, отправленные клиентом, просто измените оператор, чтобы получить имя на For Each SubmitName In Request.QueryString.
Ха-ха, спасибо за ваше терпение при чтении моей статьи^_^
Lake2