В hhtp есть косяк, так же как картинку можно загрузить с другого сайта, можно и форму отправить на другой сайт. Т.е. злоумышленник может от твоего имени отправить форму на др. сайт на котором ты залогинен, если ты случайно попадёшь на сайт злоумышленника (пройдешь по ссылке в письме например). Так можно поставить кому нибудь плюс Вконтакте от твоего имени или перевести деньги. Но злоумышленник не может увидеть этот код: 7d5ff819-b9db-4aa4-8bf1-b4c65122c4, поэтому и подделать он его не сможет. Причём код этот всегда разный (используется односторонняя функция), т.е. злоумышленник не может зайти на нужный сайт, скопировать этот код и вставить на свой плохой с которого форма отправляется.
jasonOk: там используется шифрование. Там защищено практически все, если у злоумышленника нет secret_key. Если же него есть secret_key, то он может похитить все эти данные.
jasonOk: От подобных атак легко защищают прямые руки разработчика бекенда, который должен был позаботиться чтобы любые действия (actions) от имени юзера (типа, поставить лайк) должны выполняться только через POST запросы, но никак не через GET.
khipster: URL соответствует ресурсу, получаемому методом GET. Для других HTTP-методов нет возможности сконструировать URL. (Не помню в каком RFC это прописано). Использование других HTTP-методов возможно только программно через скрипты на странице, или парсеры (для POST также существует возможность отправки через формы ввода на странице).
khipster: Я не отрицаю, что для полноценной защиты от XSS одного только POST недостаточно. Просто, POST на любые action - это то, с чего следует начинать при проектировании защищенного бекенда. А мой первоначальный комментарий относился к вопросу: "достаточно ли HTTPS для защиты от XSS?". Возможно, слово "легко" с моей стороны было лишним.
хттпс - "я уверен, что я получил страницу с того сервера с которого нужно"
защита цсрф - "сервер уверен, что данные отправлены с той страницы, которую сервер отправил пользователю"
Простой
