С тех пор, как узнал, что тире существует много видов, в диапазонах чисел использовал всегда забугорное короткое тире, именно потому, что — казалось очень уж длинным. Теперь можно будет всем говорить: «Вот видите, Тёма-сорванец со мною согласился!» )
Взломать можно абсолютно всё, это вопрос только времени и денег.
Не совсем понял, в чём суть вашего хака: я же говорю, проверяется корректность введённых данных, в частности по PCRE — пункт номер 4 в моём списке. К тому же, если вы уже авторизировались, то пробили защиту по сессиям и она, как первый уровень обороны уже более для вас не актуальна.
До этого сообщения об этом не задумывался, потому что с такими проблемами со стороны пользователя ни разу не сталкивался. В свободное время, наверное, погуглю на эту тему, возможно сделаю проверку по имени сервера желательной, но необязательной. Но, повторюсь, пока таких пользователей не встречал. Возможно, везло.
Добавлю в качестве примера, как у меня в текущем проекте происходит проверка перед выполнением действий на сайте в зоне для уже авторизированных пользователей:
1. Есть ли идентификатор пользователя в сессии пользователя (впихивается в $_SESSION при авторизации)?
2. Пришло ли с нашего сайта (по имени сервера)?
3. Пришло ли с того айпишника, с которым этот пользователь зашёл на сайт?
4. Не содержат ли передаваемые данные запрещённые символы?
5. [опционально, зависит от вида действия] Роль пользователя позволяет ему выполнять это действие?
В get-запросах стоит передавать то, что заставляет страницы выглядеть определённым образом, чтобы можно было добавлять в закладки. Всё остальное — дурной тон.
GET-запрос легко исправить, тупо изменив его в строке браузера. POST-запрос подделать сложнее, но тоже реально. Но есть механизм сессий. Но есть сниферы. И тут приходит шифрование и HTTPS. И тут злоумышленник тратится или на суперкомпьютер, чтобы поломать ключ, или на паяльник и билет до жертвы, чтобы оказать него желаемое воздействие.
Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.
В get-запросах стоит передавать то, что заставляет страницы выглядеть определённым образом, чтобы можно было добавлять в закладки. Всё остальное — дурной тон.
GET-запрос легко исправить, тупо изменив его в строке браузера. POST-запрос подделать сложнее, но тоже реально. Но есть механизм сессий. Но есть сниферы. И тут приходит шифрование и HTTPS. И тут злоумышленник тратится или на суперкомпьютер, чтобы поломать ключ, или на паяльник и билет до жертвы, чтобы оказать него желаемое воздействие.
Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.
Тут как раз вчера статья была, в которой в частности рассказывалось, что сленг не есть гуд. Вы бы почитали её и убрали «ништячки» и «смайлеги», у вас получилась бы очень достойная новость.
Буквально пару недель назад тема буквы ё активно обсуждалась на хабре, поройтесь в архиве, там есть ответы на все ваши вопросы. На вскидку вот вам ссылка по проблеме буквы ё.
1..100вне конкуренции )Не совсем понял, в чём суть вашего хака: я же говорю, проверяется корректность введённых данных, в частности по PCRE — пункт номер 4 в моём списке. К тому же, если вы уже авторизировались, то пробили защиту по сессиям и она, как первый уровень обороны уже более для вас не актуальна.
1. Есть ли идентификатор пользователя в сессии пользователя (впихивается в $_SESSION при авторизации)?
2. Пришло ли с нашего сайта (по имени сервера)?
3. Пришло ли с того айпишника, с которым этот пользователь зашёл на сайт?
4. Не содержат ли передаваемые данные запрещённые символы?
5. [опционально, зависит от вида действия] Роль пользователя позволяет ему выполнять это действие?
GET-запрос легко исправить, тупо изменив его в строке браузера. POST-запрос подделать сложнее, но тоже реально. Но есть механизм сессий. Но есть сниферы. И тут приходит шифрование и HTTPS. И тут злоумышленник тратится или на суперкомпьютер, чтобы поломать ключ, или на паяльник и билет до жертвы, чтобы оказать него желаемое воздействие.
Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.
GET-запрос легко исправить, тупо изменив его в строке браузера. POST-запрос подделать сложнее, но тоже реально. Но есть механизм сессий. Но есть сниферы. И тут приходит шифрование и HTTPS. И тут злоумышленник тратится или на суперкомпьютер, чтобы поломать ключ, или на паяльник и билет до жертвы, чтобы оказать него желаемое воздействие.
Если вы не пишите систему работы с банковскими платежами, то наверняка вам хватит POST-запросов, механизма сессий и обработки данных для отдельного пользователя только в том случае, если они пришли с того же ip, с каким он прошёл авторизацию.