Говнокод #2664 — PHP — Говнокод.ру

PHP / Говнокод #2664

+163.3
1. 1
2. 2
3. 3
4. 4
5. 5
6. 6
```
$udate = mktime(
  0,0,0,
  $_REQUEST["udate"][3] . $_REQUEST["udate"][4],
  $_REQUEST["udate"][0] . $_REQUEST["udate"][1],
  $_REQUEST["udate"][6] . $_REQUEST["udate"][7] . $_REQUEST["udate"][8] . $_REQUEST["udate"][9]
);
```
Продолжение феерической истории о том, как один мальчег не знал регулярок. Да что там регулярок...

Запостил: Johnny, 25 Февраля 2010

Tweet
Комментарии (20) RSS
- Death 25.02.2010 14:14 # +1
  
  1) как меньше писать
  $u = $_REQUEST["udate"]; // mm.dd.yyy
  $udate = mktime( 0,0,0, $u[3] .$u[4], $u[0].$u[1], $u[6].$u[7].$u[8].$u[9] );
  
  2) как нормально писать
  если у него дата уже задана в виде mm.dd.yyy, зачем вообще нужна mktime ???
  $udate = strtotime($_REQUEST[udate]);
  
  3) автору, зачем тут регулярки, но пример бредового кода налицо... +1 ???
  Ответить
  - Johnny 25.02.2010 17:10 # −0.2
    
    я бы не стал доверять все ф-и strtotime... к тому же регуляркой можно одновременно проверить корректность формата (mm.dd.yyyy) и вычленить день месяц и год для mktime.
    Ответить
    - Death 25.02.2010 18:40 # 0
      
      если юзверь введёт 32.13.8888 то mktime это кстати, прохавает, и просчитает по своемому... (причём 33.01.2000 >> 02.02.2000). зачем делать ненужные проверки регуляркой??? признак високосности года или 32 дня в году тоже там будете проверять???
      Ответить
      
      Johnny 25.02.2010 19:46 # −0.2
      
      хотя-бы затем, что поведение этой ф-и четко не документировано. "просчитает по своемому" это как?
      Ответить
      
      Death 25.02.2010 19:50 # 0
      
      Первым параметром функции должна быть строка с датой на английском языке, которая будет преобразована в метку времени относительно метки времени, переданной в now, или текущего времени, если аргумент now опущен. В случае ошибки возвращается false.
      
      $timestamp = strtotime($str);
      if ($timestamp===false)
      echo "Строка ($str) недопустима";
      Ответить
      
      Johnny 25.02.2010 20:20 # −0.2
      
      Клева! и чо дальше? Доки и я читать умею = )
      Ответить
      
      Death 25.02.2010 20:24 # 0
      
      А в чём тогда недокументированность???
      Ответить
      
      Johnny 25.02.2010 21:10 # +0.8
      
      полный список форматов дат, которые она хавает. плюс описание ее поведения, при подаче на вход некорректных дат. в одном случае она возращает значит false, а в другом пытается что-то накреативить и высрать осмысленный результат. Вон чо пишут: "The function expects to be given a string containing a US English date format and will try to parse that format into a Unix timestamp" Вилл трай... Незнаю, дело хозяйское, но в таких делах предпочитаю изобрести небольшой велосипед, чем использовать волшебные функции.
      Ответить
    - xXx_totalwar 25.02.2010 19:38 # 0
      
      регулярки? это хорошо) особенно хорошо когда:
      preg_replace() с /e
      ereg и null-байт
      Ответить
      
      Johnny 25.02.2010 19:46 # 0
      
      а, че?
      Ответить
      
      guest 25.02.2010 21:39 # +1
      
      Товарищ намекает на способ взлома через регулярки. Правда, в данном случае даже если и использовать регулярки для валидации, то уж подставлять внутрь регулярок пользовательский ввод стопудово на фиг не потребуется, так что взломом через регулярки тут не пахнет. Остаётся только согласиться: а, чё?
      Ответить
      
      Johnny 25.02.2010 22:10 # 0
      
      Как много нам открытий чудных... *ПОГНАЛ ГУГЛИТЬ*
      Ответить
      
      guest 26.02.2010 06:02 # 0
      
      трололо
      в $_REQUEST уже нельзя засунуть специально сформированные данные ?
      Ответить
      
      xXx_totalwar 26.02.2010 11:59 # 0
      
      вот и я про то же
      Ответить
      
      guest 27.02.2010 00:17 # +2
      
      Товарищи, за чем дело-то стало, давайте прояснять.
      
      preg_match('/регулярка/', $_REQUEST['anything'], $matches);
      
      Лично я - о том, что в таком случае взлом исключён, потому что регулярка задана хардкодом, и в неё из реквеста ничего не валится. Ибо я категорически затрудняюсь представить, каким боком при валидации даты может потребоваться динамически формировать регулярку, да ещё и из пользовательского ввода. Ваше слово?
      Ответить
      
      Johnny 27.02.2010 10:17 # 0
      
      Собственно в данном случае ничо через регулярку и неломаемо. А мне от пользователя xXx_totalwar хотелось бы услышать подробности про "ereg и null-байт". Это че за уязвимость?
      Ответить
      
      xXx_totalwar 27.02.2010 11:04 # +2
      
      допустим есть такая вещь
      
      if (ereg('/|(\.\.)', $_GET['page'])) die('error'); else include(trim($_GET['page']).'.html');
      
      теперь запускаем скрипт script.php?page=%00../../../../etc/passwd%00a
      Ответить
      
      guest 27.02.2010 11:10 # +1
      
      Вообще говоря, я в посте выше накосячил, потому что взлом возможен только при использовании preg_replace, ибо только эта функция поддерживает ключ /e. Но к сути. Вот пример из доки к этой функции:
      
      preg_replace("/(<\/?)(\w+)([^>]*>)/e", "'\\1'.strtoupper('\\2').'\\3'", $html_body);
      
      При использовании модификатора /e на конце регулярки второй аргумент функции интерпретируется как PHP-код, в котором \nnn заменяются на соответствующие совпадения. А теперь представим, что регулярка каким-то образом формируется из пользовательского ввода, а magic_quotes=off. В этом случае юзер может написать: блаблабла/e%00, где %00 - нуль-байт. Функция preg_replace проигнорит остаток строки, идущий после нуль-байта. В результате получим в корне изменившееся поведение регулярки - она теперь эвалит второй аргумент. Ну а дальше ловкость рук, суть которой в том, чтобы заставить регэксп отэвалить то, что нам надо. Недавно читал список уязвимостей phpBB ранних версий - так там очень много дыр завязано как раз на этой штуке.
      
      Про ereg() не знаю, принципиально им не пользуюсь, ибо медленный и deprecated.
      Ответить
      
      Johnny 27.02.2010 11:22 # 0
      
      Спасибо за разъяснение. Помню когда-то читал про это не не придал значения.
      Ответить
      
      xXx_totalwar 27.02.2010 11:14 # 0
      
      вообще то переполнение буфера в PCRE еще не отменяли
      Ответить
Добавить комментарий
Ошибка компиляции комментария:

Гости могут высказаться только в понедельник, среду, четверг или воскресение
Где здесь C++, guest?!

А не использовать ли нам bbcode?

[b]жирный[/b] — жирный

[i]курсив[/i] — курсив

[u]подчеркнутый[/u] — подчеркнутый

[s]перечеркнутый[/s] — перечеркнутый

[blink]мигающий[/blink] — мигающий

[color=red]цвет[/color] — цвет (подробнее)

[size=20]размер[/size] — размер (подробнее)

[code=<language>]some code[/code] (подробнее)

Проверочный код: *

Говнокод: по колено в коде.

PHP / Говнокод #2664

Комментарии (20) RSS

Добавить комментарий