Почему Twitter использует хэш и восклицательный знак в URL-адресах и как они переписывают URL-адреса поиска?
Мы понимаем, что хеш предназначен для поиска AJAX, но восклицательный знак? Кто-нибудь знает?
Кроме того, атрибут "действие" их формы поиска указывает на " Я сохранил свой исходный вопрос и обновленную информацию ниже для полноты картины.
[16 февраля 2011 г. - Обновление 2] Как отмечают некоторые люди, мой вопрос должен был быть следующим: Учитывая стандартную форму asp.net 4, если у меня нет проверки на стороне сервера, какие типы Я подвержен вредоносным атакам?
Вот мой вывод по этому поводу.
- Если данные не являются конфиденциальными (комментарии на странице) - с точки зрения безопасности asp.net, следование стандартным передовым методам (SqlParameters, включение проверки запросов и т. Д.) Защитит вас от злонамеренных атак.
- Для конфиденциальных данных / приложений - вам решать, какой тип проверки на стороне сервера подходит для вашего приложения. Вам нужно продумать комплексное решение (веб-сервисы, другие системы и т. Д.). Вы можете просмотреть ряд предложений ниже - проверка белого списка и т. Д.
- Если вы используете ajax (запросы xhr) для публикации пользовательского ввода, вам необходимо воспроизвести защиту от других маркеров в вашем коде на сервере. Опять же, множество решений ниже - например, обеспечение того, чтобы данные не содержали никакого html / кода и т. Д. (примечание: .net framework requestValidationMode = "4.0" действительно обеспечивает некоторую защиту в этом отношении - но я могу ' не говорите о том, насколько полно решение)
Пожалуйста, не стесняйтесь продолжать комментировать ... если что-либо из вышеперечисленного неверно, сообщите мне. Спасибо!
действительно обеспечивает некоторую защиту в этом отношении - но я не могу сказать, насколько это полное решение)Пожалуйста, не стесняйтесь продолжать комментировать ... если что-либо из вышеперечисленного неверно, сообщите мне. Спасибо!
действительно обеспечивает некоторую защиту в этом отношении - но я не могу сказать, насколько это полное решение)Пожалуйста, не стесняйтесь продолжать комментировать ... если что-либо из вышеперечисленного неверно, сообщите мне. Спасибо!
[3 февраля 2011 г. - Обновление 1] Я хочу поблагодарить всех за ответы! Возможно, мне следует задать обратный вопрос:
Предположим, что простая веб-форма asp.net 4.0 (formview + источник данных с включенной проверкой запросов) позволяет зарегистрированным пользователям публиковать комментарии на общедоступной странице (комментарии хранятся в таблице базы данных sql server) . Какой тип проверки или очистки данных я должен выполнить для новых «комментариев» на стороне сервера?
[19 января 2011 г. - исходный вопрос] На нашем веб-сайте asp.net 4 есть несколько форм, в которых пользователи могут отправлять данные, и мы используем проверку jquery на стороне клиента. Пользователи должны войти в систему с действующей учетной записью, чтобы получить доступ к этим формам.
Я понимаю, что наши правила проверки на стороне клиента можно легко обойти, и клиенты могут публиковать данные без обязательных полей и т. Д. Меня это не особо беспокоит - пользователи должны входить в систему, и я не считаю наши данные очень «Чувствительный», и я бы не сказал, что какая-либо наша проверка является «критической». Входные данные записываются в базу данных с использованием SqlParameters (для защиты от внедрения sql), и мы зависим от проверки запроса asp.net для защиты от потенциально опасного ввода HTML.
Стоит ли нам переписывать различные правила проверки jquery на сервере? В частности, как злоумышленник может взломать наш сервер или каким конкретным атакам мы можем быть подвержены?
Приношу свои извинения, поскольку похоже, что этот вопрос несколько раз обсуждался на этом сайте, но я еще не нашел ответа, в котором упоминаются конкретные риски или проблемы, связанные с невыполнением проверки на стороне сервера. Заранее благодарим