потому что это загрузка шелла, не более
Изм. 1 раз. / Посл. изм. (10 мар 2016, 16:07)
1. Потенциальный злоумышленник может обойти скрипт проверки расширения загружаемого файла, что позволит ему загрузить веб-шелл, получить контроль над приложением и доступ к серверу.
2. Уязвимость связана с манипулированием контролируемого пользователем параметра.
Как результат может привести к
мошенническим действиям при покупке товара(фрод), изменение
стоимости, подмена данных и.т.д.
Я не вижу аналогичности. Я не знаю, чего ты добиваешься. Я тебя не заставляю пользоваться моими услугами.
Изм. 2 раз. / Посл. изм. (10 мар 2016, 16:14)
По этому вопросу лучше обратится к xkat - vk.com/edicom
us{1615}
Человек знакомый по хакингу, есть опыт. Зря, что испортился.
2. дык это не уязвимость, а недоработка, баг
Уязвимость связана с манипулированием контролируемого пользователем параметра.
Как результат может привести к
мошенническим действиям при покупке товара(фрод), изменение
стоимости, подмена данных и.т.д.
http://www.cgisecurity.com/owasp/html/ch11s04.html
Денис Павлик, Я не вижу офтопа или флуда в том что тебя пытаюсь проверить . врятле за это тут бан дадут . безопасность не шутка. доверять свой сайт кому попало ,или человеку который месяц назад не знал что свойства int в базе данных ставит под сомнения знания безопасности .я конечно опечален, что ты не знаешь причём javascript и sql тут и как это связано с безопасностью. но рад что ты выучил умные слова из википедия или других информационных сайтов (достаточно текст скопировать и в гугл,кому интересно)
-----------
Если какой то опыт ,отзывы , рекомендации от людей насчёт уязвимостей ?
Какие методы устроения ,можешь ли из 13 тобой известных показать пару (хотя б одну) и её метод устроения ?
-----------
И Вообще можно ли названия этих уязвимостей (хотя б частично) ?
========
Я бы мимо прошел , по сути нечего особенного ,но вот заголовок мозолит глаза . возможно это отсутствие должного описания предоставляемых услуг
Вопрос по int был, потому что я не знал лимит. Не доходил до этого. Хотя я сам же и ответил на свой вопрос.
JavaScript какую роль он играет в безопасности? Ни какую. Если ты имеешь ввиду обработку данных на клиентской стороне, то это чушь. Пользователь может быть хакером.
Есть. Здесь на форуме только Виджик. Я закрывал ему уязвимости 1.5 года назад. Жалоб ещё не было. Как я уже сказал, что в случае взлома по моей вине я возвращаю всю оплаченную сумму.
Да. Вот, к примеру бональная XSS:
Входные данные пользователя должны строго проверяться на стороне сервера. Пользовательские параметры должны быть кодированы в HTML там где они возвращаются назад от сервера. Все специальные HTML символы, включая ([]){}< > " '` =, должны быть заменены на HTML entities (< > etc).
Запретитить использование словосочетаний alert, prompt, onerror,<div,<a, %3c,iframe,onmouseover,onload,onready,object,href
Я их уже писал. Это самые важные:
Unrestricted upload, SQL Injection, Cross-Site Scripting (XSS), Data Manipulation, CSRF, Cleartext submission of password, Sensitive information disclosure.
))) Аж интересно стало))) http://www.streamtip.ru/ 
Найди мне тут уязвимости плачу за найденые уязвимости от 500 рублей за штуку (Баги не всчет) (Писать в личку).
Изм. 1 раз. / Посл. изм. (10 мар 2016, 17:35)
