От pandas довольно легко. Для csv есть одноимённый модуль в стандартной библиотеке. Для xlsx тоже есть различные библиотеки. Т.е. я знаю про само существование pandas, даже какие-то примеры с ним видел, в статьях различных часто встречал, но на практике никогда с ним не работал (у меня питон как правило для веба и скриптов)
Для начала, не надо юлить. Жду ответа на свой вопрос: в чём Питон, Руби, Нода с жсом и АСП с шарпом «на десять лет отставали от пыхи в осознании SQL инъекций, XSS и прочих тонкостей»?
Просто интересно, как безопасность этого элемента реализуется в django? Там по умолчанию уродуется строка, путём отрывания у неё javascript: спереди?
Если говорить именно о href, то в проектах на джанге не припомню, чтобы в подобных случаях туда могли дойти данные с javascript: в начале.
Стандартный способ получения данных подразумевает использование URLValidator. Как правило, не напрямую, а в models.URLField, forms.URLField, serializers.URLField у DRF и т.п. Он по умолчанию пропускает только ссылки со схемами http, https, ftp и ftps.
Вне шаблонов такие ссылки могут формироваться в админке. Например, в последнем проекте на джанге, над которым работал, есть такой код (почистил от лишнего):
models.py
from django.conf import settings
from django.db.models import Model, URLField, SlugField
class RedirectLink(Model):
slug = SlugField(verbose_name='Слаг', unique=True)
url = URLField(verbose_name='URL')
def get_absolute_url(self):
return f'https://{settings.PUBLIC_HOST}/redirect/{self.slug}'
admin.py
import html
from django.contrib import admin
from django.utils.safestring import mark_safe
from t0links.models import RedirectLink
@admin.register(RedirectLink)
class RedirectLinkAdmin(admin.ModelAdmin):
list_display = ['id', 'slug', 'url_link', 'copy_link']
@admin.display(description='URL', ordering='url')
def url_link(self, obj: RedirectLink):
if obj.url:
url = html.escape(obj.url)
return mark_safe(f'<a href="{url}" target="_blank">🗗 {url}</a>')
@admin.display(description='Ссылка', ordering='slug')
def copy_link(self, obj: RedirectLink):
if obj.slug:
url = html.escape(obj.get_absolute_url())
return mark_safe(f'''
<button type="button" class="button" title="Скопировать с буфер обмена" style="line-height: 14px; width: 24px;" data-text="{url}"
onclick="navigator.clipboard.writeText(this.dataset.text);this.innerHTML=' ✓ ';setTimeout(() => this.innerHTML=' ⎘ ', 500);"
> ⎘ </button> <a href="{url}" target="_blank">{url}</a>
''')
Тут данные для href формируются двумя способами - получение от пользователя (поле URLField, которое ссылку на javascript: просто не пропустит) и генерация (которая тоже никак не начнёт с неё начинаться). Пробежался по всем проектам, для которых у меня ещё остались исходники, везде только эти 2 случая.
При этом https://site.ru/#"tom's_dinner" спокойно проходит и сохраняется, поэтому перед выводом в html нужно экранировать. В python3 можно использовать html.escape из стандартной библиотеки, либо использовать одну из функций django.
Также в джанге значения из кода как правило по умолчанию экранируются, поэтому строку с html нужно явно обернуть в mark_safe.
Если так триггерит href, могу поменять пример на такой:
$albumNameRaw = "Tom's dinner onload='alert(`XSS!`)";
$albumName = htmlspecialchars($albumNameRaw);
$thumb = "<img src='$thumbURL' alt='Превью альбома $albumName'>"; // в php ниже 8.1: "<img src='/path/to/preview.webp' alt='Превью альбома Tom's dinner onload='alert(`XSS!`)'>"
Не надо кликушествовать
И не собирался.
Нигде там не написано, что это "рекомендация".
Верно, равно как и не написано, что это bad practice. Я просто больше не нашёл, в чём ещё разница в "осознании SQL-инъекций" между php и остальным миром.
Все эти языки/платформы, так же как и пыха, ГОДАМИ нарабатывали навыки работы с веб
Тут полностью согласен
правда, на десять лет оставая от пыхи в осознании SQL инъекций, XSS и прочих тонкостей
А вот тут можно тут поподробнее?
Мой путь в вебе протекал через php/yii и js, затем python/django плюс эпизодически другие фреймворки для питона, нода (js и ts) и го, теперь снова в основном php, но symfony, плюс эпизодически питон, го и ts.
И мой опыт говорит о прямо противоположном. Львиная доля попадавшихся мне XSS приходится на php-проекты. Это либо напрямую вывод данных от пользователя в представлении yii (там шаблонизатор по умолчанию — сам php), либо код вида:
в php ниже 8.1 (который вышел в 2021 году). У остальных же, "отстающих в осознании", стандарт де-факто — использование шаблонизаторов, в которых экранирование включено по умолчанию, и для появления XSS нужно делать дополнительные телодвижения.
С SQL инъекциями тоже интересно. Если отойти от мира ORM, то только в php я видел в документации рекомендации пихать внешние данные прямо в строку запроса, "экранировать только не забывай правильно". А кто забудет, получит уязвимость. У остальных стандартная практика — биндинги.
По "прочим тонкостям". Из указанного списка только в php возможна ситуация, когда при кривой настройке сервера пользователь может через форму на сайте залить файл скрипта (shell, adminer и т.п.) в какую-нибудь директорию upload и выполнить его, просто запросив /upload/adminer.php.
В общем, по моим наблюдениям, это именно с пыхой нужно специально сильно пыхтеть для обеспечения мало-мальской безопасности.
От pandas довольно легко. Для csv есть одноимённый модуль в стандартной библиотеке. Для xlsx тоже есть различные библиотеки. Т.е. я знаю про само существование pandas, даже какие-то примеры с ним видел, в статьях различных часто встречал, но на практике никогда с ним не работал (у меня питон как правило для веба и скриптов)
Это же вроде ограничение на размер загружаемого файла. Речь о том, что при превышении получим 413 в ответ.
Вариант 1 — затолкать в качестве комментариев собрание произведений Льва Толстого (насколько знаю, количество COM в JPEG не ограничено)
Вариант 2 — rarjpg
Для начала, не надо юлить. Жду ответа на свой вопрос: в чём Питон, Руби, Нода с жсом и АСП с шарпом «на десять лет отставали от пыхи в осознании SQL инъекций, XSS и прочих тонкостей»?
Если говорить именно о
href
, то в проектах на джанге не припомню, чтобы в подобных случаях туда могли дойти данные сjavascript:
в начале.Стандартный способ получения данных подразумевает использование URLValidator. Как правило, не напрямую, а в models.URLField, forms.URLField, serializers.URLField у DRF и т.п. Он по умолчанию пропускает только ссылки со схемами
http
,https
,ftp
иftps
.Вне шаблонов такие ссылки могут формироваться в админке. Например, в последнем проекте на джанге, над которым работал, есть такой код (почистил от лишнего):
models.py
admin.py
Тут данные для
href
формируются двумя способами - получение от пользователя (полеURLField
, которое ссылку наjavascript:
просто не пропустит) и генерация (которая тоже никак не начнёт с неё начинаться). Пробежался по всем проектам, для которых у меня ещё остались исходники, везде только эти 2 случая.При этом
https://site.ru/#"tom's_dinner"
спокойно проходит и сохраняется, поэтому перед выводом в html нужно экранировать. В python3 можно использовать html.escape из стандартной библиотеки, либо использовать одну из функций django.Также в джанге значения из кода как правило по умолчанию экранируются, поэтому строку с html нужно явно обернуть в mark_safe.
Если так триггерит
href
, могу поменять пример на такой:И не собирался.
Верно, равно как и не написано, что это bad practice. Я просто больше не нашёл, в чём ещё разница в "осознании SQL-инъекций" между php и остальным миром.
Тут полностью согласен
А вот тут можно тут поподробнее?
Мой путь в вебе протекал через php/yii и js, затем python/django плюс эпизодически другие фреймворки для питона, нода (js и ts) и го, теперь снова в основном php, но symfony, плюс эпизодически питон, го и ts.
И мой опыт говорит о прямо противоположном. Львиная доля попадавшихся мне XSS приходится на php-проекты. Это либо напрямую вывод данных от пользователя в представлении yii (там шаблонизатор по умолчанию — сам php), либо код вида:
в php ниже 8.1 (который вышел в 2021 году). У остальных же, "отстающих в осознании", стандарт де-факто — использование шаблонизаторов, в которых экранирование включено по умолчанию, и для появления XSS нужно делать дополнительные телодвижения.
С SQL инъекциями тоже интересно. Если отойти от мира ORM, то только в php я видел в документации рекомендации пихать внешние данные прямо в строку запроса, "экранировать только не забывай правильно". А кто забудет, получит уязвимость. У остальных стандартная практика — биндинги.
По "прочим тонкостям". Из указанного списка только в php возможна ситуация, когда при кривой настройке сервера пользователь может через форму на сайте залить файл скрипта (shell, adminer и т.п.) в какую-нибудь директорию
upload
и выполнить его, просто запросив/upload/adminer.php
.В общем, по моим наблюдениям, это именно с пыхой нужно специально сильно пыхтеть для обеспечения мало-мальской безопасности.
ipu6 передаёт привет. В ядре 6.10 какие-то драйвера для них добавили, но моя OVTI02C1 туда не попала. Распознаётся, что есть, но данные с неё не идут
Со встроенными динамиками похожая ситуация - они определяются, всё выглядит рабочим, но звука от них нет
Samsung Book4 и debian trixie. В bookworm также wi-fi и тачпад не завелись (примечательно, что тачскрин работал)