- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте, уважаемые, хотел бы продолжить эту тему.
Сейчас нахожусь в напряженном поиске решения по безопасности связки ajax + php.
Короче говоря, я пришел к выводу: извращаться с хэшами, обфускацией, временем жизни хэша и прочее можно долго, но это вопрос терпения программиста, который захочет поломать мою систему. Причина проста - абсолютно всё, что выполняется в браузере, можно повторить через curl+интерпретатор js. То есть, эта задача нерешаема топологически.
И как же тогда никто не ломает вконтакт и иже с ними? Может кто знает, какие технологии там применяются?
Fail2ban вам в помощь.
А какая разница в плане безопасности - ajax или нет ? Тот же самый запрос к серверу.
В чем конкретно ваша проблема безопасности? Данные проверяйте на сервере. Все.
Очень странный вопрос.
Безопасность внутри должна решаться.
Сильную валидацию данных сделайте и пускай отправляем вам на сервер что хочет).
AVR55, от чего защититься-то нужно? если нужно данные по открытому каналу передавать, то через https шлёшь и всё. хэши можно сессиями заменить и не изобретать пятое колесо
Ничего другого кроме контоля IP и создания хороших сессий (в плане размерности именования) не придумано. Не ломайте голову.
В вашем случае - смотрите в сторону прав доступа к файлам, и вызовам подпрограмм.
Ну это же азы безопасности.
я пришел к выводу: извращаться с хэшами, обфускацией, временем жизни хэша и прочее можно долго, но это вопрос терпения программиста, который захочет поломать мою систему. Причина проста - абсолютно всё, что выполняется в браузере, можно повторить через curl+интерпретатор js. То есть, эта задача нерешаема топологически.
Конкретно по ссылке задача тривиальная, решается введением доп. параметра - токена:
token = timestamp + ';' + sha1(timestamp + secret)
Т.к. secret известен только на сервере, то у третьей стороны нет возможности подделать токен, когда вызывается код со второй страницы, не выполнив код с первой страницы, т.е. исходная задача решена. Для защиты от повторного использования токена можно проверять timestamp, что не просрочен более чем на несколько минут.
---------- Добавлено 05.06.2016 в 06:15 ----------
абсолютно всё, что выполняется в браузере, можно повторить через curl+интерпретатор js
Нельзя, например CSS :)