Podatności Divi theme

Motyw Divi dla WordPressa jest podatny na Stored Cross-Site Scripting przez atrybut `skype_url` w module Social Media Follow we wszystkich wersjach do 4.27.6 włącznie. Wynika to z trójstopniowej awarii sanityzacji: pole nie jest na białej liście, renderowanie pomija esc_url(), a tylko sanitize_text_field() jest stosowane, co pozwala na złamanie atrybutu. Uwierzytelnieni atakujący z dostępem na poziomie Contributor i wyżej mogą wstrzykiwać skrypty.

Motyw Divi dla WordPress jest podatny na Stored Cross-Site Scripting przez parametr `redirect_url` w shortcode `et_pb_contact_form` we wszystkich wersjach do 4.27.6 włącznie. Atrybut `redirect_url` jest sanityzowany funkcją `esc_attr()` zamiast `esc_url()` przed renderowaniem do atrybutu HTML `data-redirect_url`. Dodatkowo `redirect_url` nie znajduje się w tablicy `$url_options` w `class-et-builder-element.php`, więc nie otrzymuje sanityzacji `esc_url_raw()` podczas parsowania shortcode. Po udanym wysłaniu formularza JavaScript po stronie klienta odczytuje ten atrybut i przekazuje go bezpośrednio do `window.location.href`, wykonując dowolny JavaScript z URI `javascript:`. Umożliwia to uwierzytelnionym atakującym z dostępem na poziomie Contributor i wyżej wstrzyknięcie dowolnych skryptów, które wykonają się, gdy użytkownik wyśle formularz kontaktowy.

Motyw Divi dla WordPressa jest podatny na trwały cross-site scripting przez funkcję Dynamic Content w starszym formacie JSON we wszystkich wersjach do 4.27.6 włącznie. Wynika to z dwóch nakładających się wad: (1) filtr sanityzacji przy zapisie `et_builder_sanitize_dynamic_content_fields()` szuka tylko znaczników dynamicznej treści w formacie `@ET-DC@...@`, ale silnik renderujący obsługuje również starszy format JSON, który jest po cichu konwertowany w czasie renderowania, całkowicie omijając filtr przy zapisie, oraz (2) resolver `post_meta_key` w `et_builder_filter_resolve_default_dynamic_content()` nie stosuje `wp_kses_post()` do rozwiązanej wartości meta, gdy `enable_html` jest ustawione na `on`, przekazując surowe dane z `get_post_meta()` bezpośrednio na stronę. To umożliwia uwierzytelnionym atakującym z dostępem na poziomie Współautora i wyżej wstrzykiwanie dowolnych skryptów na strony, które wykonają się, gdy użytkownik odwiedzi zainfekowaną stronę.