Поиск ошибок и улучшений в ПОПрименительно на web-интерфейсах,

сайтах и cs.stu

Максим МирошниченкоWebProduction

SQL-инъекция(SQL-injection)

SELECT * FROM `table` WHERE `id`=’{$x}’;

$x = 10

$x = 10’ OR 1=1 OR id=’1

SELECT * FROM `table` WHERE id=’{$x}’;

+

$x = 10’ OR 1=1 OR id=’1

=

SELECT * FROM `table`WHERE `id`= 10’ OR 1=1 OR id=’1’

Инъекция в оператор SELECT как правило безобидна

(для mysql начиная с 3.23 и выше)

Но инъекция в DELETE сносит всю таблицу!А инъекция в UPDATE “уничтожает” все данные!

DELETE FROM `table` WHERE `id`=’{$x}’;

Если получиться передать в $x кавычки - всем данным в таблице наступит конец.

DELETE FROM `table`WHERE `id`=’1’ OR 1=1 OR id=’2’;

http://frontzmin.org/view_post.php?id=992это означает, что где-то есть update :)

Экранируйте одинарные кавычки!

$x = mysql_escape_string($x);или

$x = str_replace(“ ‘ ”, “ \’ ”, $x);или

просто не пишите sql-запросы руками :)

Проверить ресурс на SQL-инъекцию:

добавьте в URL к параметру одинарную кавычку и просто смотрите, что будет :)

На cs.stu в API есть методы,которые допускают инъекции,

но нету контроллеров,которые эти методы вызывают ;)

Да, это был баг.Но не критичный :)

А нужно было показывать страницу 404...

XSSCross-site-scripting

Пассивный XSS - это всего-лишь прямой вывод GET/POST-параметра в страницу.

Активный XSS - это возможность сделать запрещенную вставку (img, js, flash) в

комментарий, публикацию и т.д.

http://.../page.html?param=</script><script>alert(‘BUGAGA!’);...

На cs.stu вроде-как нету активныхXSS-уязвимостей :)

А раньше были...

Как с бороться с XSS:

Активный XSS: проверяйте данные, которые сохраняете от пользователей.

Пассивный XSS: если параметр из URL приходится показывать на странице -

проверяйте его.

Поиск ошибок и улучшений в формах

ввода

Опять кавычки, но уже двойные :)

<input type=”text” value=”данные” ... />

<input type=”text” value=”данные” ... />

+

если пользователь ввел в данные двойную кавычку

=

<input type=”text” value=”дан”ные” ... />

Это уже баг.

<input type=”text” value=”дан”ные” ... />

<input type=”text” value=”дан” /> <script> alert(‘XSS’);</script>” ... />

Это пассивный XSS.

На cs.stu в формах нету пассивного XSS, но разорвать <input> двойной кавычкой можно.

Баг.

Ошибки и улучшения в полях ввода дат

Любимый и правильный формат дат для разработчиков:

yyyy-mm-dd hh:ii:ss(Y-m-d H:i:s)

Но 99% пользователей его на дух не переносят :)

Пользователи могут ввести:2009-12-09

09-12-09 - фатальный вариант

2009.12.0912.09.200912,09,200912 09 2009

09/12/2009 - фатальный вариант для англоязычных (формат d/m/y)

12/09/2009 - фатальный вариант для русскоязычных (формат m/d/y)

09/12/09 - фатальный вариант

2009 Dec 99 dec 09 и еще +100500 вариантов

Чтобы все остались довольны:

1. Дату, которую вводит пользователь проганяем через strtotime или аналоги.

2. Добавляем каледарик для поля ввода.

3. Формат даты по умолчанию делаем в соответствии с локалью пользователя/севера.

(тяжело)

Исключения для дат рождения

Но если пользователю приходиться заполнять сотни полей с датами (админу, модератору), то:

dd-mm-yydd-mm-yyyy

dd.mm.yydd.mm.yyyy

Поле для ввода емейла:

1. Нужна проверка формата xxx@xxx.com2. Нужна проверка формата xxx.xxx@xxx.com

(спасибо GMail)

Если при ошибочном заполнении формы введенные данные слетают, пользователь

второй раз форму не заполнит.

Обращайте внимание на длинну и порядок полей ввода

Поиск “орфографических” визуальныхошибок

(и не только орфографических)

Выравнивания по ширине в web’e НЕТ!

Тире − это &mdash;Минус − это “-”

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

Расположение элементовна страницах

Как все происходит,если нету тестирования...

http://pm.stu.cn.ua/

max@webproduction.com.ua