Предотвращение нападений на XSS
Я думаю, что может быть не хватает какого-то кода, поэтому я не могу подтвердить, но, похоже, вы не установили BALL-OWNER как черепаху или патч, а вместо этого присвоили значение непосредственно этой переменной. of запрашивает переменную у агента (или список переменных из набора агентов), поэтому, если для BALL-OWNER установлено значение, NetLogo запутывается. Однако если вы назначаете агента для BALL-OWNER, ваш подход должен работать нормально. Например, попробуйте выполнить код ниже:
to setup
ca
crt 10 [
setxy random-xcor random-ycor
set color one-of [ red blue ]
]
reset-ticks
end
to go
let ball-owner one-of turtles
ifelse [color] of ball-owner = red [
print "red team has possession"
] [
print "blue team has possession"
]
end
Редактировать: Вы можете определенно использовать global, чтобы выбрать цвет, как вы делали во втором блоке кода - я просто хотел бы отметить, что of конкретно связано с agents. Если вы хотите сохранить цвет в переменной global для сравнения, это возможно, просто сравнение проще, чем использование of:
globals [ initial-possession ]
to setup
ca
crt 3
set-initial-possession
reset-ticks
end
to go
ask turtles [
decision
]
end
to set-initial-possession
set initial-possession ifelse-value ( random 2 = 1 ) [black] [white]
end
to decision
ifelse initial-possession = black [
print "I see that black has possession"
] [
print "I see that white has possession"
]
end
Я не уверен, поможет ли это, в первую очередь это может зависеть от вашей цели сохранить цвет в global!
6 ответов
Использование javascript (как я думаю, вы говорите) для экранирования не кажется слишком безопасным. Он работает на компьютере пользователя, и они могут с некоторыми усилиями обойти механизм экранирования.
То, что вы пытаетесь сделать, звучит правильно, но вам нужно делать это на стороне сервера.
Несколько замечаний:
- Как сказал @Alo, это должно быть сделано на стороне сервера, чтобы злоумышленник не смог полностью обойти ваш javascript и отправить вредоносный ввод непосредственно на сервер , Однако, как вы отметили, это следует делать (в определенных ситуациях) ТАКЖЕ на стороне клиента, чтобы предотвратить XSS на основе DOM.
- Вы упомянули, что страница имеет кодировку UTF-8, вам необходимо обеспечить это с помощью метатегов. , Заголовки HTTP и т. Д. В противном случае вы уязвимы для атак UTF-7.
- Пробелы - это буквенно-цифровые символы или нет? (некоторые включают это ...) Используя просто пробел и буквы, в некоторых ситуациях МОЖЕТ быть проведена полномасштабная атака XSS.
Дополнительные сведения см. В моем ответе на Предотвращает ли кодирование HTML все виды XSS-атак? Здесь вы найдете все, что вам нужно знать.
Примечание для дополнения других замечаний:
Убедитесь, что вы правильно используете GET и POST, потому что это простейшая брешь в безопасности на многих веб-сайтах.
Если вводится пользователем будет запускать любое изменение в базе данных, убедитесь, что вы используете POST.
Только пользовательский GET, если вы получаете информацию для отображения.
Кодирование подходит. Самый большой потенциальный риск - это то, что вы делаете с данными и если / когда данные декодируются / отображаются. Если вы декодируете ввод пользователя и отображаете его, декодируя данные, тогда у вас могут возникнуть проблемы.
Если у вас нет острой необходимости поддерживать символы, которые более опасны с точки зрения потенциальных уязвимостей XSS (например, '<', '>', ';' и т. Д. ), то я думаю, что разумно занести в черный список и этих персонажей. Таким образом, если вы декодируете и отображаете данные, вы не будете потенциально выражать проблему XSS.
Это звучит безопасно, и, вероятно, так и есть, но здесь есть загвоздка. Он работает, только если вы правильно его реализовали . Слишком легко ошибиться. Если вы хотите пойти на это, ничего страшного, но я бы посоветовал использовать для этого несколько уже протестированных библиотек, а не кататься самостоятельно.
The basic way to defend against XSS is to use regular expressions to validate input whenever possible and to encode all output. Encoding output can be tricky, so it is best to use a library. Tt least one important input to your application is filenames, so you would want a regular expression that would match any valid filename for your target OS. Accepting only alphanumeric input would make it impossible for your app to handle many filenames on common operating systems. I don't follow why using %hex values would do any good. There's no reason a malicious script can't be encoded that way. The same script can have many valid utf-8 representations. You need to do some more background reading on anti-XSS coding practices. Google OWASP for references.