- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
<form>
<input name=userid type=text>
<input name=password type=text>
<input name=email text=text>
<input type=submit>
</form>
public class User {
private String userid;
private String password;
private String email;
private boolean isAdmin;
//Getters & Setters
}
@RequestMapping(value = "/addUser", method = RequestMethod.POST)
public String submit(User user) {
userService.add(user);
return "successPage";
}
d_fomenok 14.10.2017 18:06 # +3
Более того: эта уязвимость встречается очень часто.
PS. Ещё одна: habrahabr.ru/post/340066
inho 14.10.2017 18:11 # 0
SemaReal 14.10.2017 23:31 # +5
bormand 15.10.2017 06:52 # +4
А вообще, там же должен быть какой-то механизм для валидации перед записью в базу, иначе и в логин всякой херни понасуют.
inkanus-gray 15.10.2017 06:53 # 0
bormand 15.10.2017 06:58 # +2
А вот в сторону хтмл - вполне возможно. Ну как минимум ник с невидимыми пробелами, чтобы под кого-то другого косить. Или RTLом вёрстку пидорасить. Ну или с zalgo пофаниться на худой конец.
SemaReal 15.10.2017 08:05 # +3
Эскейпить надо перед выводом.
Перед выводом в HTML надо превращать в entities.
Перед выводом в PDF не нужно.
Это совсем не значит что в базе надо запрещать что-то хранить
bormand 15.10.2017 09:06 # +1
Заведёт кто-нибудь учётку SemaReal и будет от твоего имени постить всяких гомонигров. Ничего страшного же?
Или зарегается как SemaReal и распидорасит разметку.
Всё-таки для многих полей стоит задать разумные ограничения, даже если всё корректно эскейпится на выводе.
SemaReal 15.10.2017 09:40 # +1
но запрещать символ в модели просто потому что он один из вью (пусть и самый важный) его не умеет -- это фейл
bormand 15.10.2017 11:08 # +2
Здесь тонкая грань, блин...
Для тех же сообщений или описаний товаров - да, согласен. Пусть вьюха сама разбирается с этим говном.
Но писать функцию, которая делает визуальное сравнение джвух юникодных строк, сложно и дорого. Имхо, ограничение на допустимые символы в userid'е будет разумным компромиссом.
SemaReal 15.10.2017 16:29 # 0
все что старше 127 точно нахуй
inkanus-gray 15.10.2017 16:43 # +1
SemaReal 15.10.2017 16:45 # −1
Тоже самое я делаю для полей с емейлом. Им тоже не нужны символы за пределами a-zA-Z_0-9-.
gost 15.10.2017 17:15 # +3
Начальник! Начальник, бля! Уберите от меня этого мудака!!! Идите мойте его, нахуй, я с ним здесь сидеть не буду, блядь!
SemaReal 15.10.2017 17:21 # 0
У тебя почта в домене .рф?
inkanus-gray 15.10.2017 18:16 # 0
Может быть, у него в юзернейме плюсик или ещё какой-нибудь символ?
SemaReal 15.10.2017 18:27 # +1
Вообще говоря перед собачкой можно что угодно, но SMTP должен уметь проходить через семибитные кодировки и это надо учитывать.
Но если ты точно знаешь что он не пойдет через них (например потому что ты шлешь почту на тот же сервер) то пиши что угодно: главное чтобы сервер понял
inkanus-gray 15.10.2017 18:39 # +2
Они укладываются в семибитную кодировку, но не проходят через некоторые самопальные фильтры.
1024-- 15.10.2017 18:45 # −2
Годится для проверки адресанта на трезвость или защиты от подбора адреса спамерами по словарю.
SemaReal 16.10.2017 23:46 # +1
Регулярка для проверки адреса занимает четверть листа A4, и редко когда используется.
>>C=CA/ADMD=TELE
Запахло LDAP / X.500
>>user%host
Запахло еще какой-то древней почтовой сетью, чем-то типа UUCP.
inho 15.10.2017 13:18 # +4
inkanus-gray 15.10.2017 13:20 # +1
gost 15.10.2017 14:01 # 0
SemaReal 15.10.2017 16:30 # +2
она как раз уникодная
gost 15.10.2017 17:18 # −1
UTF16 - ересь!
SemaReal 15.10.2017 16:30 # +3
"koi8-r"
"win-1251"
"mac-cyr"
чтобы пользователь сам выбирал
я всегда так делаю
1024-- 15.10.2017 17:42 # −1
SemaReal 15.10.2017 18:05 # 0
так было много, много лет назад
inho 15.10.2017 13:20 # 0
KoderOT-Boga 17.10.2017 01:00 # 0
SemaReal 17.10.2017 01:02 # 0
Там учат писать код с XSS и SQL инъекциями
_PHP_ 29.03.2019 13:17 # 0
guest8 29.03.2019 14:37 # −999