Что является лучшей альтернативой для QueryString

Question

Мы много слышали об уязвимостях использования QueryStrings и возможных атак. Кроме того, вчера, ошибка раздражает меня так много, что я просто решил прекратить использование QueryStrings, я проходил что-то вроде:

Dim url As String = "pageName.aspx?type=3&st=34&am=87&m=9" 

Я попытался

Response.Write(url) 

на странице перенаправления, он напечатал «тип» как 3, затем я попробовал его на целевой странице, он напечатал 3,0 .... я знаю, что с этим можно легко справиться, но почему? я имею в виду, почему я должен пройти 3 и должен проверить на 3.0 в загрузке следующей страницы, чтобы принять мои действия соответственно?

Итак, что мы должны использовать? какой самый безопасный способ передать переменные, параметры ... и т. д. на следующую страницу?

Answer 1

Лучший/самый безопасный способ передачи информации между страницами - использовать сеанс.

// On page 1: 
this.Session["type"] = 3; 

// On Page 2: 
int type = (int)this.Session["type"]; 

Вы можете хранить любые объекты в сессии, и она хранится на стороне сервера, так что пользователь не может манипулировать им, как строки запроса, ViewState, или скрытого поле

Answer 2

Вы можете использовать Cross-Page Postbacks.

Проверьте также в этой статье:

• How to: Pass Values Between ASP.NET Web Pages

Answer 3

Есть много вариантов, которые вы можете использовать, большинство из них требует, чтобы построить стратегию, чтобы передавать переменные между страницами.

В большинстве проектов я использую эту стратегию, я создаю класс formVariables для хранения активных элементов. у него есть свойства, которые вам нужно будет пройти по querystring. и я храню этот класс на сеансе. и на моей базовой странице я прочитал его с сеанса. поэтому на каждой странице я получаю значения над этим объектом. единственная негативная вещь в этом методе - очистить предметы, когда вы закончили свою работу над этим.

надеюсь, что это поможет.

Answer 4

Во-первых, в asp .net вы можете использовать несколько стратегий, чтобы передавать значения между страницами. У вас тоже есть viewstate, однако хранилище данных сохраняет значение, а использование - в разных сценариях, вы также можете использовать его. Сессии вместо этого, и, конечно, по почте в форме.

Если проблема связана с безопасностью, я рекомендовал вам создать 2 пользователей для доступа к данным. Один пользователь с доступом только для чтения, для доступа к страницам (Sql Inyection предотвращает) и проверки данных бросает запрос. И один с доступом для записи для вашей частной зоны.

Извините, за мой невыносимый английский.

Answer 5

Если вы выполняете надлежащие проверки безопасности при каждой загрузке страницы, то запрос выполняется в порядке и наиболее гибко ИМХО.

Они обеспечивают максимальную гибкость, поскольку запись poitn на страницу не зависит от отправителя, как в некоторых других вариантах. Вы можете вызывать страницу из любой точки вашего собственного приложения или извне, если это необходимо, с помощью querystrings. Они также могут быть помещены в закладки и изменены вручную для тестирования или прямой обработки.

Снова ключ добавляет правильную безопасность и валидацию к querystring, а не обрабатывает ее вслепую. Имейте в виду, что seucirty выходит за пределы доступа к редактированию или чтению, в зависимости от данных и пользователя, у них может не быть доступа к данным с помощью parasers вообще, в тех случаях, когда данные принадлежат частным пользователям и являются частными.

Мы попытались использовать различные методы, чтобы скрыть запрос, но в конце концов вернулись к нему, так как его легче выполнять, отлаживать и управлять.

Answer 6

Мне нравится использовать строку запроса, так как я люблю, чтобы пользователи могли добавлять закладки, подобные обычным поискам и тому подобное. Например. если страница может работать автономно, то мне нравится, чтобы она могла работать автономно.

Использование сеансовых/межстраничных обратных передач - это круто, если вам нужно перейти с другой страницы для страницы, на которой вы находитесь, чтобы иметь смысл, но в остальном я обычно считаю, что запросы являются лучшим решением.

Просто помните, что строки запроса являются неутвержденным вводом и обрабатывают их с осторожностью, если вы будете рассматривать любой неутвержденный ввод.

Answer 7

Вы сказали:

напечатанное 3,0 .... я знаю, что это может быть легко рассмотрены, но почему? я имею в виду, почему я должен пройти 3 и должны проверить 3.0

Там разница между «3,0» (три запятой ой) и «3.0» (три точки ой). Вы также сказали, что «проходили что-то вроде».

В строке запроса, если вы передаете несколько значений в одном ключе, они будут разделены запятыми.

Поскольку все значения передаются как строки, нет никакого способа, чтобы int "3" собирался волшебным образом стать десятичным "3.0", если вы его не проанализируете как таковой, когда вы его запрашиваете.

я бы вернуться назад и дважды проверьте, что вы передаете в ваш URL, если он заканчивается как что-то вроде:

pageName.aspx?type=3&st=34&am=87&m=9&type=0 

Тогда, когда вы читаете назад

Request.QueryString["type"] 

Вы будете получите «3,0» назад в качестве разделенного запятой списка значений в этом ключе.

Answer 8

Я бы sugest вы избегаете использования Session для передачи переменных между страницами, так как это нарушает модель без учета состояния сети. , если вы только что сохранили некоторые значения в сеансе, которые относятся к определенной странице, тогда пользователь использует свою кнопку назад для возврата к той же странице, у которой должно быть другое состояние, после чего вы не узнаете об этом.

Это приводит к возможности считывать значения сеанса, которые не имеют отношения к странице, которую просматривает пользователь в настоящее время. Это потенциально очень запутанно для конечного пользователя. Вы также столкнетесь с проблемами с истечением сеанса, если будете полагаться на него слишком много.

Я лично стараюсь избегать использования сеанса, где это возможно, в предпочтении скрытых значений формы + строки запроса, которые можно прочитать при обратной передаче + навигация.