Безопасно ли это клиентское приложение? - PullRequest
Новая
       22

Безопасно ли это клиентское приложение?

0 голосов
/ 04 ноября 2018

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

HTML: 

<input id='myinput' type='file' accept='.png, .jpg, .jpeg' />

Javascript: 

 var myinput = document.getElementById('myinput');
 myinput.addEventListener('change', function(e) {

   /* 1. capture the file */
   var file = e.target.files[0];

   /* 2. make a fileReader object */
   var reader = new FileReader();

   /* 3. the load event listener */
   reader.addEventListener('load', function(e) {
     var fileContentAsText = e.target.result; // <-- is this line safe?
     /* 5. functions for manipulating the file would go here */
   }, false); 

   /* 4. passing the file to the filereader object */
   reader.readAsText(file);

 });

Более или менее, моя программа предназначена для манипулирования файлами типа png или jpg, манипулирования ими, а затем для предоставления модифицированной версии для скачивания.

Все происходит на стороне клиента.

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

Если бы я отправлял его на сервер, почти все, что я сделал бы для проверки файла, было бы в php, и я был бы разумно уверен, что операция была достаточно безопасной.

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

Актуальные вопросы:

  1. Учитывая, что все будет происходить на стороне клиента, нужно ли проверять файл?
  2. Если так, то почему? И какие действия я могу предпринять?

Что приходит на ум, это текстовые поля, которые устанавливают innerHTML других элементов, или где атрибуты src / onerror могут использоваться для гнусных целей. Нужно ли следить за этими типами атак? Потому что все, что я прочитал по этому вопросу, касается проверки файла, который отправляется на сервер.

Ответы [ 2 ]

0 голосов
/ 04 ноября 2018

Вы должны знать об уязвимостях, таких как, например, межсайтовый скриптинг, открытое перенаправление, хранение конфиденциальной информации (не полный список), которые также могут влиять на клиентские приложения.

На практике это означает, что важной частью является точка 5. в комментариях - что происходит с загруженным файлом. Например, вы можете сохранить часть этого после обработки в скажем localStorage, что может представлять риск, если хранится «конфиденциальная» информация (будь то в вашем контексте). Или, например, если часть записывается обратно клиенту (что, я думаю, имеет место, если я правильно понимаю), это может представлять угрозу для инъекции. Самым простым внедрением будет XSS, если вы, например, напишите что-нибудь в html, как комментарий из изображения exif. Но вы также должны учитывать, что происходит с результирующим файлом после того, как пользователь получит результат. Будет ли оно отображаться в приложении, которое может быть уязвимо для какой-либо инъекции или, например, переполнения буфера? Рассмотрим средство просмотра изображений с известной уязвимостью переполнения буфера. Скажем, злоумышленник готовит изображение и передает его жертве. Это изображение может быть создано таким образом, чтобы оно не приводило непосредственно к переполнению буфера, но после преобразования, которое ваше приложение выполняет с ним, оно использует уязвимости в клиенте, который его отображает. Конечно, это уязвимость стороннего клиентского программного обеспечения, но ваше приложение использовалось, чтобы скрыть эксплойт и облегчить атаку.

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

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

Кроме того, во время обработки части информации об изображении могут использоваться, например, для запросов, например, для поиска поставщика камеры по информации exif или чего-либо еще. Такие запросы также могут быть подвержены инъекции, что приводит к подделке запросов через вредоносное изображение. Поэтому все, что вы читаете из файла во время обработки, должно рассматриваться как ненадежное, как если бы это было сделано на сервере.

0 голосов
/ 04 ноября 2018

Клиентская сторона никогда не будет в безопасности. Даже если вы используете атрибут accept в input type="file", он только идентифицирует открытое диалоговое окно, чтобы идентифицировать данные типы и отображать только их. Но пользователь все равно может выбрать вариант Select All и выбрать любой тип файла. И reader.readAsText(file); будет читать как и не будет проверяться. Это означает, что хакер может загрузить все, что пожелает, и вставить в приложение. Таким образом, всегда рассматривайте возможность проверки на языке сервера.

затем создание модифицированной версии

Это не имеет никакого смысла, поскольку приложение может загружать что угодно, а не файлы указанных типов.

...