Почему шифруют строки запроса в ASP.NET?
.xls файлы используют формат BIFF. Файлы .xlsx используют Office Open XML, который является форматом zip XML. BIFF - это не заархивированный формат; файлы, использующие этот формат, не распознаются библиотеками zip. - shmee
blockquote>преобразование в .xlsx является решением
import win32com.client as win32 fname = "full+path+to+xls_file" excel = win32.gencache.EnsureDispatch('Excel.Application') wb = excel.Workbooks.Open(fname) wb.SaveAs(fname+"x", FileFormat = 51) #FileFormat = 51 is for .xlsx extension wb.Close() #FileFormat = 56 is for .xls extension excel.Application.Quit()
11 ответов
Причина, почему Вы могли бы сделать что-то вроде этого, состоит в том, чтобы предотвратить подделку в URL для получения доступа к данным кроме собственного. Например, если у Вас есть URL:
http://foo.com/user.aspx?user_id=123
мне (или никто) не было бы трудно изменить это на:
http://foo.com/user.aspx?user_id=124
Если Ваша стратегия доступа к данным полагается полностью на то, что находится в querystring, который мог предоставить несанкционированный доступ к данным.
Этот подход действительно служит той цели правильно, но более устойчивый способ добраться там состоит в том, чтобы активно проверить авторизацию в рамках приложения и никогда не полагаться исключительно на URL для аутентификации и / или цели авторизации.
Обратите внимание, что это не имеет никакого отношения к SSL - который гарантирует конфиденциальность между браузером и сервером, но можно являться объектом совершенно безопасного соединения и все еще вмешаться в URL.
Ну, возможно это позволяет Вам распределять URL для страницы, но лучший подход здесь мог бы быть чем-то включающим гуид как непрозрачный идентификатор к постоянной ссылке..., возможно, это полезно для сценариев целей?
Если это между страницами на том же приложении, то POST по SSL, действительно казалось бы, имел бы больше смысла. Можно ли спросить исходных разработчиков? Прочитать документы дизайна?
Если шифрование сделано на более низком уровне в приложении, или если это - платформа. Это могло быть должно гарантировать, что содержание защищено независимо от реализации. Это все еще защищено, даже если разработчик решает не использовать POST SSL.
Я вижу шифрование querystring как что-то полезное... Позволяет говорят, что Вы хотите предотвратить пользователя для изменения? recordID=1 к? recordID=2
Я знаю, что это должно быть защищено на pageload, но все мы знаем, что не все делают это
IMO Вы правы быть смущенными этой практикой, потому что это - просто не хорошая идея. Существует предел тому, сколько данных Вы можете (в зависимости от браузера) и должны вставить QueryString.
Они могут быть полезными в таких вещах как пользовательские активации, куда Вы передаете в учетных данных учетной записи простого текста от браузера непосредственно (хотя это легко разрешено с маркером поиска). Полезно, где SSL не доступен для запросов POST, и это в единственные времена, о которых я могу думать, чтобы быть честным. Это может часто применяться как принудительное требование от клиента для остановки случайной утечки данных, но я предполагаю, что это зависит от паранойи приложения.
Причина querystrings шифруются, состоит в том, потому что она предлагает поддельную безопасность. Это позволяет чувство деловых людей, что это предлагает безопасность, когда все, что это действительно предлагает, является obstufcation, который не является никакой безопасностью.
В моем предыдущем задании мы были вынуждены использовать их, и я прояснил, что было абсолютно бессмысленно особенно, когда у нас был статический ключевой и статический вектор инициализации, но все еще люди думали, что это предлагало что-то.
Причина это очень плохо для использования зашифрованных строк запроса, это позволяет людям не реализовать реальную безопасность. В случаях, где другие пользователи указали, у Вас есть www.mysite.com/page?userid=25, который они могут легко изменить 25, чтобы быть 100 или 1 и т.д.
По-моему, это - хорошая вещь, пользователи должны смочь сделать это. Это до веб-сайта, чтобы гарантировать, чтобы они не изменили идентификатор и получили доступ к несанкционированным материалам. Слишком легко не реализовать реальную безопасность, когда кажется, что Вы защищены.
Относительно шифрования строки запроса я могу действительно думать о многих причинах зашифровать его. Вероятно, классический случай был бы тем, где Вы создали сетку, заполненную исключительно индексируемыми записями человека. В каждой строке можно хотеть иметь ссылку на страницу, которая разрешает Вам редактировать запись. Вы могли просто дать каждой ссылке аргумент, такой как "ID=X" для загрузки соответствующей записи.
John | Sample | <a href="EditPage.aspx?ID=1">Edit Me!</a>
Jane | Sample | <a href="EditPage.aspx?ID=2">Edit Me!</a>
Теперь, это не проблема, если у всех сотрудников есть доступ ко всему персоналу, И доступ к Вашей странице пропускается процессом аутентификации, И Вы используете SSL (SSL согласовывается, и вся коммуникация шифруется, прежде чем любые аргументы url отправляются). Однако рассмотрите случай, где у Вас есть ограничения, на которых пользователи видят который записи. Так, штат в Чикаго может только видеть людей, присвоенных Чикагскому району, нью-йоркский штат может только видеть нью-йоркский персонал и т.д.
Теперь у Вас есть проблема: кто-то мог поставить под угрозу Ваше ограничение местоположения путем простого перепечатывания URL с другим идентификатором пользователя. Один путь вокруг этого состоит в том, чтобы зашифровать аргументы запроса. Существует несколько изгибов и поворотов, все же. Во-первых, простое шифрование не работало бы, потому что пользователь мог просто попробовать другое зашифрованное значение. Вам были бы нужны включенные пары или алгоритм, который привел к чрезвычайно редкому отображению между идентификаторами и аргументами url. Включенное парное решение (то, которое я использовал и рекомендовал бы), легко: просто передайте два зашифрованных, сложных значения, которые сотрудничают для приведения к допустимому значению.
Обратите внимание, что Вы не можете обойти это через устройство хранения данных сессии, потому что Вы не знаете то, что оценивает пользователя, собирается выбрать заранее. Точно так же Сообщение было бы очень неуклюже в обработке такого простого устройства интерфейса.
Относительно Вашей ситуации, вышеупомянутые шоу определенная ситуация, где это было бы полезно. Применяется ли это в Вашем случае, чтобы Вы решили. Вы должны однако, рассматривать, реализовали ли шифрование они просто замены одно отгадываемое значение для другого.
Другое примечание: состояние отображения не шифруется по умолчанию. Это просто кодируется через Base64. Хеш добавляется так, чтобы Вы видели, вмешались ли в него.
Насколько безопасность Вашего веб-приложения идет, единственный надежный способ гарантировать, что данные, которые Вы получаете, прибывают от Вашего пользователя и что данные не были поставлены под угрозу в передаче, через SSL.
Что касается ViewState, это уже зашифровано и проверено в значительной степени каждым возможным способом Временем выполнения ASP.NET.
Разговор о requrest URL (или строки запроса) - лично я не вижу никакой смысл в шифровании их, потому что нет никакого нормального оправдания за то, что сделали это.
Кажется, что дешевый-и-веселый способ отговорить пользователей играть с ПОЛУЧАЕТ параметры. Я знаю, что играю с, ЗАСТАВЛЯЮТ параметры получать то, что я хочу.
Что кажется нечетным, тем не менее, это ДОБИРАЕТСЯ, запросы, отправленные из JavaScript, должны были бы закодировать URL, также. Это будет мешать делать сайт интерактивным в AJAX-y путь. В той точке кажется активно вредным иметь в распоряжении систему.
Если бы у меня было голосование, то я голосовал бы;
- перепишите анализирующие URL механизмы, таким образом, они принимают и зашифрованные и незашифрованные строки,
- отметьте функцию шифрования URL как
[Obsolete] - постепенно удаляйте систему шифрования.
В дополнение ко всем приведенным ответам вы можете скрыть данные URL из журналов сервера.