The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"В WordPress молча устранена уязвимость, позволяющая изменить..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от opennews (??), 03-Фев-17, 12:44 
В опубликованном 26 января корректирующем обновлении WordPress 4.7.2 (https://wordpress.org/news/2017/01/wordpress-4-7-2-security-... без лишней огласки была устранена критическая уязвимость (https://blog.sucuri.net/2017/02/content-injection-vulnerabil... позволяющая удалённому атакующему без аутентификации изменить содержимое любой страницы через манипуляцию с REST API. Разработчики WordPress пояснили (https://make.wordpress.org/core/2017/02/01/disclosure-of-add... отсутствие упоминания об исправлении уязвимости в анонсе тем, что они лишь придержали публикацию уведомления, желая дождаться пока будет установлено обновление у как можно большего числа пользователей, чтобы предотвратить волну атак и вандализма.


Проблема проявляется только в выпусках WordPress 4.7 и 4.7.1, более ранние версии не подвержены проблеме, даже при включении плагина REST API. REST API по умолчанию включён начиная с ветки 4.7 и предоставлет альтернативный способ манипуляции с настойками, комментариями и публикациями. Уязвимость была обнаружена 20 января исследователями из компании  Sucuri в процессе реализации инициативы по аудиту открытых проектов. Разработчики WordPress оперативно выпустили обновление и при участии сетей доставки контента
Incapsula, Cloudflare и SiteLock убедились, что в трафике не встречаются попытки эксплуатации данной уязвимости, после чего решили на несколько дней придержать сообщение о проблеме.

Уязвимость вызвана особенностью обработки передаваемых через REST API значений, в частности, передаваемые через $_GET и $_POST параметры имели более высокий приоритет в обработке, чем параметры, закодированные внутри пути. Воспользовавшись данной особенностью атакующий мог передать запрос с идентификатором, включающим не только цифры, но и буквы, и обойти таким образом проверки на наличие полномочий для выполнения операции.


Например, вместо штатного запроса "/wp-json/wp/v2/posts/1234" можно отправить "/wp-json/wp/v2/posts/1234?id=5678helloworld", для которого значение парамера "?id=" будет иметь более высокий приоритет, чем идентификатор в пути "/1234". При проверке прав доступа проверяется наличие идентификатора "5678helloworld" и так как он не найден и не привязан к владельцу, передаётся управление в вызов get_post, который должен завершить запрос не найдя страницу. Но перед вызовом функции get_post осуществляется приведение переменной к целому типу и вместо "5678helloworld" передаётся значение "5678", указывающее на существующую страницу, что приводит не к выходу, а к вызову метода update_item. Отмечается, что в зависимости от используемых плагинов уязвимость может привести не только к подстановке своего содержимого на страницу, но и к выполнению произвольного PHP-кода на сервере.


URL: https://blog.sucuri.net/2017/02/content-injection-vulnerabil...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45974

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Аноним (-), 03-Фев-17, 12:44 
Сейчас эксперты придут и скажут, что дело вовсе не в кривом дизайне похвпэ и что никто уже не использует $_GET и $_POST и вообще Word Press г о в н о к о д.
Ответить | Правка | Наверх | Cообщить модератору

3. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +4 +/
Сообщение от A.Stahl (ok), 03-Фев-17, 12:48 
Это плата за слишком вольное неявное приведение типов.
По каким-то причинам современные программисты очень боятся выделять/освобождать память и приводить типы самостоятельно.
Ответить | Правка | Наверх | Cообщить модератору

5. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +7 +/
Сообщение от asand3r (?), 03-Фев-17, 12:56 
Потому что это "сложо, неэффективно, небезопасно, пока я буду этим заниматься, можно написать еще сотню строк кода".
Ответить | Правка | Наверх | Cообщить модератору

23. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Sw00p aka Jerom (?), 03-Фев-17, 15:05 
>>небезопасно

небезопасная только потомучто сишная malloc такая ?

Ответить | Правка | Наверх | Cообщить модератору

38. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –4 +/
Сообщение от Аноним (-), 03-Фев-17, 17:26 
Аналогия некорректная. "PHP" - не язык программирования, а всего лишь шаблонизатор, соответственно и планка для него должна быть как для шаблонизатора. Уродливый дизайн, нет внятных исключений и т. д.? Так это потому, что он и не создавался как язык программирования.
Ответить | Правка | Наверх | Cообщить модератору

41. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –2 +/
Сообщение от Sw00p aka Jerom (?), 03-Фев-17, 17:46 
какая аналогия ? о чём речь?

>>Так это потому, что он и не создавался как язык программирования.

таки да - об этом говорю не я а сам автор, пхп не ЯП, а апликейшен сервер написанный на С.

Ответить | Правка | Наверх | Cообщить модератору

66. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –3 +/
Сообщение от Я. Р. Ош (?), 04-Фев-17, 01:23 
> нет внятных исключений

О да, как же нубам без исключений, их же другому и не учили


Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

72. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +3 +/
Сообщение от Аноним (-), 04-Фев-17, 05:37 
PHP:

json_decode("null"); // => NULL
json_decode("хах, я тоже null"); // => NULL

JavaScript:

JSON.parse("null"); // => null
JSON.parse("а вот и не null"); // => SyntaxError: Unexpected token а in JSON at position 0

-------

Задача: распарсить два числа из поля number двух объектов из двух строк с JSON, сложить их и вывести результат. Если что-то пошло не так, вывести сообщение об ошибке.

PHP:

$object1 = json_decode($string1);
if (json_last_error() !== JSON_ERROR_NONE) {
  echo "Error: " . json_last_error_msg();
} else {
  $object2 = json_decode($string2);
  if (json_last_error() !== JSON_ERROR_NONE) {
    echo "Error: " . json_last_error_msg();
  } else {
    echo "Result: " . $object1->number + $object2->number;
  }
}

JavaScript:

try {
  console.log(`Result: ${JSON.parse(string1).number + JSON.parse(string2).number}`);
} catch (err) {
  console.log(`Error: ${err.message}`);
}

Ответить | Правка | Наверх | Cообщить модератору

7. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +7 +/
Сообщение от Gemorroj (ok), 03-Фев-17, 13:11 
>> кривом дизайне похвпэ

в данном случае вообще не при чем.
>> "/wp-json/wp/v2/posts/1234?id=5678helloworld", для которого значение парамера "?id=" будет иметь более высокий приоритет, чем идентификатор в пути "/1234"

это недоработка чисто вордпресовская, легко можно представить подобное в любом другом веб проекте (имею ввиду неверную расстановку приоритетов для получения значения переменной).

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

8. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –4 +/
Сообщение от Добрый анон (?), 03-Фев-17, 13:15 
>это недоработка чисто вордпресовская, легко можно представить подобное в любом другом веб проекте (имею ввиду неверную расстановку приоритетов для получения значения переменной).
> легко можно представить подобное в любом другом веб проекте

Это напрямую и означает, что глобальные (!) супермассивы вроде $_POST и $_GET можно напрямую использовать неправильно, и более того, делать это достаточно легко! Что в свою очередь ведет к кривому дизайну самого ПХП и громадному количеству легаси-кода, который написан с подобными допущениями.

Ответить | Правка | Наверх | Cообщить модератору

34. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от amonymous (?), 03-Фев-17, 16:47 
> Это напрямую и означает, что глобальные (!) супермассивы вроде $_POST и $_GET
> можно напрямую использовать неправильно, и более того, делать это достаточно легко!
> Что в свою очередь ведет к кривому дизайну самого ПХП и
> громадному количеству легаси-кода, который написан с подобными допущениями.

А при чём тут пост и гет? Тут речь о том, что вообще произвольные строки в качестве чисел использовать нежелательно.

Блин, сколько ж лет учат криворучек валидировать весь юзеринпут. Да хоть РЕГЕКСПАМИ, да. А воз и ныне там.

Ответить | Правка | Наверх | Cообщить модератору

45. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от Square1 (?), 03-Фев-17, 19:40 
смешно в этом то, что вы не посмотрели код, доверившись только пересказу новости.
а между тем, именно так там и сделали.. валидировали регекспом :)
Ответить | Правка | Наверх | Cообщить модератору

9. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от КО (?), 03-Фев-17, 13:19 
Причем тут приоритеты?
Когда в одном месте при анализе параметра _5678helloworld_ это 5678helloworld, а в другом 5678. Не удивлюсь, что id=0x162E мог себя вести аналогичным образом.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

12. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Gemorroj (ok), 03-Фев-17, 13:24 
js:
parseInt('5678helloworld'); //5678
---
это проблема всех динамических языков, или даже приведения типов. а не конкретно php.
Ответить | Правка | Наверх | Cообщить модератору

14. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от ss (??), 03-Фев-17, 13:52 
Я эту ошибку отношу исключительно на счет вордпресса, поскольку гуляние параметра по разным фильтрам "авось в какойнить подойдет" - это проблема не языка программирования, а конкретного программиста наваявшего подобное...
Ответить | Правка | Наверх | Cообщить модератору

18. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +5 +/
Сообщение от Аноним (-), 03-Фев-17, 14:19 
> js:
> parseInt('5678helloworld'); //5678
> ---
> это проблема всех динамических языков,

Ну-ну.


-- lua
> print(tonumber("5678"))

5678
> print(tonumber("5678helloworld"))

nil

% введение
1 ?- atom_number('5678helloworld',X).
false.

2 ?- atom_number('5678',X).                          
X = 5678.

2 ?- number_chars(Num, "1234").
Num = 1234.

3 ?- number_chars(Num, "1234HelloWorld").  
ERROR: number_chars/2: Syntax error: Illegal number

#tcl
% expr "123"
123
% expr "123Hello"
invalid bareword "123Hello"
in expression "123Hello";
should be "$123Hello" or "{123Hello}" or "123Hello(...)" or ...

# любимейший язык анонимов с убунтой
>>> int('5678helloworld')

Traceback (most recent call last):
  File "<input>", line 1, in <module>
    int('5678helloworld')
ValueError: invalid literal for int() with base 10: '5678helloworld'
>>> int('5678')

5678

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

21. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –2 +/
Сообщение от Gemorroj (ok), 03-Фев-17, 14:57 
Кстати про любимый язык анонимов с убунтой:
print 6 + "123";
> unsupported operand type(s) for +: 'int' and 'str'
Ответить | Правка | Наверх | Cообщить модератору

43. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +4 +/
Сообщение от Аноним (-), 03-Фев-17, 18:35 
> Кстати про любимый язык анонимов с убунтой:
> print 6 + "123";
>> unsupported operand type(s) for +: 'int' and 'str'

Типа, строгая типизация === зло?


>>> print str(6) + "123"

6123
>>> print 6 + int("123")

129
>>> myint=type('myint', (int,), dict(zip(('__add__','__radd__'), [lambda x,y: int.__add__

(x,y) if all(map(isinstance,[x,y],[int,int])) else str(x) + str(y)]*2)))
>>> '3' + myint(4)

'43'
>>> 3 + myint(4)

7
>>> 3 + myint(4) + myint(7)

14
>>> "3" + myint(4) + myint(7)

'743'

Ответить | Правка | Наверх | Cообщить модератору

49. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –4 +/
Сообщение от anomymous (?), 03-Фев-17, 21:23 
>>> (x,y) if all(map(isinstance,[x,y],[int,int])) else str(x) + str(y)]*2)))

Вот здесь вырвало.

Ответить | Правка | Наверх | Cообщить модератору

51. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +3 +/
Сообщение от Аноним (-), 03-Фев-17, 21:33 
>>>> (x,y) if all(map(isinstance,[x,y],[int,int])) else str(x) + str(y)]*2)))
> Вот здесь вырвало.

Держите нас и далее в курсе ваших "достижений" и мы, возможно, когда-нибудь перепишем этот однострочник, идущий как PoC с типами, на что-то, соответсвующее "низкому порогу вхождения" и понятное любому школьнику.

Ответить | Правка | Наверх | Cообщить модератору

82. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от anomymous (?), 05-Фев-17, 01:06 
Нубы всегда такие нубы. Лет через 5 предложите новому коллеге прочитать ваш код. Почитайте с ним вместе. Посмейтесь над тем, что ни хрена быстро не прочли. После чего задумайтесь.

Ответить | Правка | Наверх | Cообщить модератору

86. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 05-Фев-17, 07:10 
> Нубы всегда такие нубы. Лет через 5 предложите новому коллеге прочитать ваш
> код. Почитайте с ним вместе. Посмейтесь над тем, что ни хрена
> быстро не прочли. После чего задумайтесь.

А еще здесь тестов нет, да и документация отсутсвует!
В общем, ламы такие ламы. Они не знают, что такое PoC, зато готовы спустя 5 лет читать свой код на форумах.


Ответить | Правка | Наверх | Cообщить модератору

22. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +3 +/
Сообщение от freehckemail (ok), 03-Фев-17, 15:04 
Продолжаем эстафету. :)


Схема. Racket v6.1.
1       > (string->number "11")
2       11
3       > (string->number "11zxc")
4       #f

Common Lisp (SBCL v1.2.4)
1       * (parse-integer "11")
2       11
3       * (parse-integer "11zxc")
4       debugger invoked on a SB-INT:SIMPLE-PARSE-ERROR in thread

Perl (v5.20.2)
1       $ print "11zxc" + 0
2*      Argument "11zxc" isn't numeric in addition (+) at - line 1.
3       11
4       $ print "zxc11" + 0
5*      Argument "zxc11" isn't numeric in addition (+) at - line 1.
6       0
[*] Для этих строк надо включить use warnings.
    Однако даже с use strict, скрипт с ошибкой не сваливается.
    Похоже, это камень в огород Perl.

Zsh (v5.0.7)
1       % x=11zxc
2       % let x+=0
3       zsh: bad math expression: operator expected at `zxc'

Bash (v4.3.30)
1       $ x=11zxc
2       $ let x+=0
3       bash: let: 11zxc: value too great for base (error token is "11zxc")


Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

24. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Sw00p aka Jerom (?), 03-Фев-17, 15:06 
> js:
> parseInt('5678helloworld'); //5678
> ---
> это проблема всех динамических языков, или даже приведения типов. а не конкретно
> php.

пхп не ЯП сам создатель об этом говорил, забудьте про него и весь холивар про теорию типов.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

54. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 03-Фев-17, 23:06 
можно пруфы где создатель такое говорил.
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

77. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Sw00p aka Jerom (?), 04-Фев-17, 15:23 
любителям читать пруфы

https://habrahabr.ru/company/idcee/blog/202890/
https://habrahabr.ru/company/edison/blog/315680/

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

15. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 03-Фев-17, 13:54 
Это вполне себе обычное дело для языков с нестрогой типизацией. Если человек не знает этого и садится кодить на пхп или жс, то для него есть особое название - быдлoкодер. Но никоим образом это не может быть претензией к языку, который изначально создавался с нестрогой типизацией, и в котором реализация оной выполнена как надо.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

25. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –2 +/
Сообщение от Sw00p aka Jerom (?), 03-Фев-17, 15:12 
> Это вполне себе обычное дело для языков с нестрогой типизацией. Если человек
> не знает этого и садится кодить на пхп или жс, то
> для него есть особое название - быдлoкодер. Но никоим образом это
> не может быть претензией к языку, который изначально создавался с нестрогой
> типизацией, и в котором реализация оной выполнена как надо.
>>с нестрогой типизацией

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

Ответить | Правка | Наверх | Cообщить модератору

37. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Crazy Alex (ok), 03-Фев-17, 17:17 
тем не менее сишники в типах как-то не путаются. Динамика - это вообще заботливо разложенные грабли.
Ответить | Правка | Наверх | Cообщить модератору

42. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Sw00p aka Jerom (?), 03-Фев-17, 17:59 
> тем не менее сишники в типах как-то не путаются. Динамика - это
> вообще заботливо разложенные грабли.

не путаются эт по какой причине ? по той, что компилятор на столько тугодум не знает в скольких ячейках памяти сохранить результат ? а динамические чем отличаются тогда ? умом, что знают об этом ? Асм-му ваще по** на ваши инты, чары, флоаты он для этого юзает "корзинки" (регистры) конкретного размера для результатов вычислений.


Ответить | Правка | Наверх | Cообщить модератору

78. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от www2 (ok), 04-Фев-17, 20:54 
Не путайте динамическую типизацию с нестрогой типизацией - это разные вещи. В Python динамическая типизация, но строгая.
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

81. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от S00p aka Jerom (?), 04-Фев-17, 22:54 
В математике все сводится к строгости
Ответить | Правка | Наверх | Cообщить модератору

62. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Led (ok), 03-Фев-17, 23:29 
> Если человек садится кодить на пхп или жс, то для него есть особое название - быдлoкодер.

//fixed

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

29. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +2 +/
Сообщение от amonymous (?), 03-Фев-17, 16:43 
Дело именно в гуанокоде.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

63. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от Led (ok), 03-Фев-17, 23:31 
> Дело именно в гуанокоде.

Кидаться гуанокодом - это нормальное поведение вэб-макак.

Ответить | Правка | Наверх | Cообщить модератору

65. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Я. Р. Ош (?), 04-Фев-17, 01:21 
>Сейчас эксперты придут и скажут

Ты уже пришел

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

67. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от pda (?), 04-Фев-17, 01:25 
> никто уже не использует $_GET и $_POST

Да? А чем там теперь пользуются?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от Аноним (-), 03-Фев-17, 12:45 
Новости про баги вордпресса (да какие там баги, зияющие дыры) выходят так регуляно, что уже стали чем-то обычным
Ответить | Правка | Наверх | Cообщить модератору

4. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от поледанныхотсутств (?), 03-Фев-17, 12:48 
Использование wordpress, почти равносильно..
Ответить | Правка | Наверх | Cообщить модератору

30. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от amonymous (?), 03-Фев-17, 16:43 
> Использование wordpress, почти равносильно..

Жумлы ещё. С друпальчиком.

Ответить | Правка | Наверх | Cообщить модератору

6. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 03-Фев-17, 13:00 
> молча устранена уязвимость

..., кроме того молча добавлен новый вид бекдора...

Ответить | Правка | Наверх | Cообщить модератору

10. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +9 +/
Сообщение от бедный буратино (ok), 03-Фев-17, 13:20 
автор, который вносил это, проиграл своему коллеге 5000 рупий - ибо таки спалили
Ответить | Правка | Наверх | Cообщить модератору

11. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +7 +/
Сообщение от PavelR (??), 03-Фев-17, 13:24 
>манипуляции с настойками

))

Ответить | Правка | Наверх | Cообщить модератору

13. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +3 +/
Сообщение от Аноним (-), 03-Фев-17, 13:31 
2017года а у ВП ничего нового.
Ответить | Правка | Наверх | Cообщить модератору

16. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от Аноним (-), 03-Фев-17, 14:04 
С ошибками приведения типов бороться сложно, неявное приведение могло произойти и в MySQL. А вот то что один модуль решает, что запись с заданным id не найдена, а потом другой спокойно с ним что-то делает - это, имхо, полный бардак в архитектуре.
Ответить | Правка | Наверх | Cообщить модератору

17. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Lolwat (?), 03-Фев-17, 14:15 
Я одни делаю проверки regEx перед тем как использую значения?
И как люди пользуются WP?
Да и вообще, я видел бизнеса которые клипаю магазины и всякие веб сервисы  на WP. Вот как так? Руки нужно отрубать таким девелоперам по самую шею
Ответить | Правка | Наверх | Cообщить модератору

27. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от angra (ok), 03-Фев-17, 15:55 
Ты гордишься тем, что как обезьянка повторяешь технику без попытки осмысления?
Если мне надо проверить существует ли переданный объект, то я просто сделаю if exists $pages{$page}. Что к этому добавит проверка регексом? Если какой-то параметр должен быть числом, то зачем его пропускать через проверку регексом, если все-равно после этого он пройдет через конвертацию в число? В данном случае причина фейла не в том, что не воспользовались регексом, а в том, что одни и те же по сути проверки существуют в разных местах, разными способами и вызываются более одного раза в процессе обработки запроса.

Ответить | Правка | Наверх | Cообщить модератору

36. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +3 +/
Сообщение от amonymous (?), 03-Фев-17, 16:49 
В вёбе ВЕСЬ юзеринпут должен быть завалидирован без допущений. Независимо от языка.
Ответить | Правка | Наверх | Cообщить модератору

64. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от angra (ok), 04-Фев-17, 01:18 
А не в вебе уже можно не заниматься валидацией? А в вебинтерфейсе "для себя" недоступном миру валидировать точно нужно? Ну и самое главное, регекс это единственный способ валидации?
Ответить | Правка | Наверх | Cообщить модератору

83. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от anomymous (?), 05-Фев-17, 01:08 
> А не в вебе уже можно не заниматься валидацией? А в вебинтерфейсе
> "для себя" недоступном миру валидировать точно нужно? Ну и самое главное,
> регекс это единственный способ валидации?

Нет, можете валидировать хоть чем, разрешаю. Главное - валидировать корректно.

Ответить | Правка | Наверх | Cообщить модератору

48. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от lolwat (?), 03-Фев-17, 20:14 
> Ты гордишься тем, что как обезьянка повторяешь технику без попытки осмысления?

очень даже осмысленно

>Если мне надо проверить существует ли переданный объект, то я просто сделаю if exists $pages{$page}. Что к этому добавит проверка регексом?
>>В вёбе ВЕСЬ юзеринпут должен быть завалидирован без допущений. Независимо от языка.  -  мудрый аноним

"if exists $pages{$page}" -  очень глупо, в зависимости от реализации Hash, это может привести к коллизиям.

>Если какой-то параметр должен быть числом, то зачем его пропускать через проверку регексом, если все-равно после этого он пройдет через конвертацию в число?

B том что нужно было слать лесом запрос /wp-json/wp/v2/posts/1234?id=5678helloworld в самой ранней стадии (это конечно если id всегда Number). да и RegEx не только, что я использую - я еще все фильтрую параметры, то есть там где я не жду id,  я верну тебе HTTP 400.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

68. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от angra (ok), 04-Фев-17, 01:27 
> "if exists $pages{$page}" -  очень глупо, в зависимости от реализации Hash,  это может привести к коллизиям.

Коллизия это конечно очень страшное слово, можно пугать им джуниоров, но что если тебе попадется кто-то более опытный и попросит тебя рассказать о последствиях такой коллизии? Только во взрослом ЯП, а не в какой-нибудь студенческой наивной реализации hash/map. Вдруг окажется, что единственное последствие это небольшой провал производительности.

> B том что нужно было слать лесом запрос /wp-json/wp/v2/posts/1234?id=5678helloworld в
> самой ранней стадии (это конечно если id всегда Number).

А с этим кто-то спорил? Попробуй все-таки прочитать внимательно, что именно произошло.


Ответить | Правка | Наверх | Cообщить модератору

84. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от anomymous (?), 05-Фев-17, 01:09 
if exists $pages{$page} - не глупо, а очень глупо, поскольку скорее всего pages не существует, и page передаётся куда-то в запрос. Я не про вордпресс конкретно, я про вообще.
Ответить | Правка | Наверх | Cообщить модератору

35. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от amonymous (?), 03-Фев-17, 16:49 
> Я один делаю проверки regEx перед тем как использую значения?

Ты не одинок, нет. Про остальное согласен.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

20. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –2 +/
Сообщение от Аноним (-), 03-Фев-17, 14:54 
Что вы думаете о MODX?
Ответить | Правка | Наверх | Cообщить модератору

50. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от anomymous (?), 03-Фев-17, 21:24 
> Что вы думаете о MODX?

Позитивчик.

Ответить | Правка | Наверх | Cообщить модератору

56. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от Аноним (-), 03-Фев-17, 23:07 
Лучше о нём не думать...
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

74. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 04-Фев-17, 07:01 
Тоже похапе -> сорта одного и того же.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

26. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от klalafuda (?), 03-Фев-17, 15:51 
> осуществляется приведение переменной к целому типу и вместо "5678helloworld" передаётся значение "5678"

Ну Семен Семеныч!

И не надо мол PHP опять виноват. С таким подходом ребят никакой инструмент не спасет.

Ответить | Правка | Наверх | Cообщить модератору

31. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Виталий (??), 03-Фев-17, 16:44 
Как можно больше обновятся, если будут знать о проблеме!!!
Ответить | Правка | Наверх | Cообщить модератору

33. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от freehckemail (ok), 03-Фев-17, 16:45 
> Разработчики WordPress пояснили отсутствие упоминания об исправлении
> уязвимости в анонсе тем, что они лишь придержали публикацию
> уведомления, желая дождаться пока будет установлено обновление у как
> можно большего числа пользователей, чтобы предотвратить волну атак и
> вандализма.

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

Анонсы исправлений уязвимостей должны быть побуждающим фактором для обновления, а не наоборот. Публиковать такие вещи надо сразу же.


Ответить | Правка | Наверх | Cообщить модератору

40. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –2 +/
Сообщение от Нанобот (ok), 03-Фев-17, 17:42 
>приведение переменной к целому типу и вместо "5678helloworld" передаётся значение "5678"

занимательная php-математика :)

Ответить | Правка | Наверх | Cообщить модератору

69. "В WordPress молча устранена уязвимость, позволяющая изменить..."  –1 +/
Сообщение от Линукс еще не готов (?), 04-Фев-17, 01:55 
Должен быть единое место получения параметров. И должна быть однозначнисть, где прячется ид , в пути или в параметрах
Ответить | Правка | Наверх | Cообщить модератору

75. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 04-Фев-17, 11:47 
Если пэхэпэ такой прогнивший, то что юзать?
Ответить | Правка | Наверх | Cообщить модератору

79. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от www2 (ok), 04-Фев-17, 20:56 
> Если пэхэпэ такой прогнивший, то что юзать?

Статические HTML-сайты.

Ответить | Правка | Наверх | Cообщить модератору

80. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 04-Фев-17, 21:47 
Предлагаю вообще не пользоваться интернетом и компом. И жить в лесу.
Ответить | Правка | Наверх | Cообщить модератору

88. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 06-Фев-17, 02:57 
Слез кстати с докувики на такой в своём бложеке. Доволен. Брат жив.
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

85. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от anomymous (?), 05-Фев-17, 01:11 
> Если пэхэпэ такой прогнивший, то что юзать?

Православный питончик же. Или рабьку. Или растик. Ну с рантаймом год по***ться придётся на каждый проект, и при апдейтах ещё. Проблем-то. Рынок же на месте стоит, конкуренции нет, можно и академично подойти.

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

90. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Фанат PHP и Wordpressemail (?), 13-Фев-17, 09:06 
> Православный питончик же. Или рабьку.

Угу, вот только PHP 7 по производительности всухую уделывает рабьку с питончиком. Intel, к слову, сотрудничает с командой PHP, оптимизируя их процессоры конкретно под этот ЯП. Пока ребята пишут высокопроизводительные сайты, пишите свои тормозные жигули на рабьке с питончиком))

Ответить | Правка | Наверх | Cообщить модератору

89. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +/
Сообщение от Аноним (-), 09-Фев-17, 02:13 
gantry + grav
Ответить | Правка | Наверх | Cообщить модератору

91. "В WordPress молча устранена уязвимость, позволяющая изменить..."  +1 +/
Сообщение от Айкemail (?), 22-Апр-17, 13:33 
Молодцы разработчики,всегда обновляют и держат руку на пульсе,вордпресс рулит !
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру