Почему внедрение кода JavaScript - плохая идея - PullRequest
Новая
       12

Почему внедрение кода JavaScript - плохая идея

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

У меня есть веб-проект, который разработан asp.net

В моем веб-проекте у меня есть страница, которая называется (MainPage). В MainPage в соответствии со строкой запроса последний пользователь может увидеть форму редактирования опроса (www.a.com?entity=survey@op=edit) или форму вставки параметра (www.a.com?entity=parameter&op=add) или и т.д ....

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

Например: www.a.com?saşlfas571=sflkmlm11sd&13kjn13=1378183

Кроме того, в MainPage я загружаю javascript, называемый MainPageJs, и он показывает правильные js-коды в соответствии со строкой запроса.

Я загружаю MainPageJs в MainPage.cshtml 

@section scripts{

<script type="text/javascript" src="@CustomUrl.CustomAction("MainPageJS", "Home", new { entity= entityName, op = opName })"></script>

}

Следующий код показывает, как работает MainPageJs 

 ....
 string res = "";
 if (queryString == "parameter")
 {
       res = "var a = 1;";
 }
 if (queryString == "survey")
 {
      res = "var a = 2;";
 }
 if (queryString == "user")
 {
      res = "var a = 3;";
 }

 return JavaScript(res.ToString());

Теперь мне интересно то, что,

  1. Есть ли у моего стиля кода проблемы с безопасностью?
  2. Имеет ли моя веб-страница какую-либо уязвимость безопасности?
  3. Имеет ли этот стиль уязвимость внедрения кода JavaScript?

Ответы [ 3 ]

0 голосов
/ 11 ноября 2018 
Does my code style have any security problems?
Does my web page have any security vulnerability?
Does this style have a JavaScript code injection
vulnerability?

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

Вот несколько причин.

  1. Вы открыли свой URL для общественности. Даже если вы закодируете это, некоторые люди будут пытаться взломать его. Например, с разных URL хакер может его расшифровать. Я предпочитаю скрывать это и не дать им шанс. Также вы можете использовать URL как более читаемый ресурс для поисковой системы.

  2. Если вы не используете framework, вам может понадобиться реализовать фильтр параметров для предотвращения атаки Injection (SQL, JS). Требуется время.

  3. Сложно поддерживать код. Поскольку ваш код смешан с ASP и JS, становится все труднее, когда ваш код больше, особенно когда вы работаете с View как HTML с JS в коде ASP.

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

Если вы шифруете на стороне клиента, пользователь может реально увидеть, что отправляется в приложение, прежде чем оно будет зашифровано. Существуют инструменты для отслеживания активности на стороне клиента (например, YSlow ), и злонамеренный пользователь с техническим опытом может использовать его для обнаружения возможных внешних уязвимостей. Не забывайте никогда не доверять пользовательскому вводу, и разрешение пользователю передавать код инъекции в ваше приложение никогда не будет хорошим выбором.

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

у моего стиля кода есть проблемы с безопасностью?

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

У моей веб-страницы есть уязвимость в безопасности?

нет. Вы не можете ничего сломать, выполняя динамический код на клиенте. «Динамический» код выполняется в той же песочнице с теми же привилегиями, что и ваш обычный js.

У этого стиля есть уязвимость внедрения кода javascript?

Некоторые люди используют термин " Атака JavaScript Injection * " - для обозначения побочных эффектов $( userInput ).insertAfter( .. ); - когда пользователь может запустить некоторый JavaScript из входных данных пользователя (если userInput содержит <script>...</script>), но это не связано с динамическим JS, это больше о динамическом HTML.

...