По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Разработчики программного обеспечения должны держать много информации у себя в голове. Существует множество вопросов, которые нужно задать, когда речь заходит о создании веб-сайта или приложения: Какие технологии использовать? Как будет настроена структура? Какой функционал нам нужен? Как будет выглядеть пользовательский интерфейс? Особенно на рынке программного обеспечения, где производство приложений больше похоже на гонку за репутацией, чем на хорошо обдуманный процесс, один из важнейших вопросов, который часто остается на дне “Списка важных”: Как наш продукт будет защищен?
Если вы используете надежный, открытый фреймворк для создания своего продукта (и, если он доступен и пригоден, почему бы и нет?), тогда базовые проблемы безопасности, как атаки CSFR и кодирование пароля, могут быть уже решены за вас.
Тем не менее, быстро развивающимся разработчикам будет полезно освежить свои знания о стандартных угрозах, дабы избежать ошибок новичка. Обычно самое слабое место в безопасности вашего программного обеспечения - это вы.
А кто может заниматься взломом?. Есть этичный хакер – это тот, кто ищет возможные слабости в безопасности и приватно рассказывает их создателям проекта.
А чёрный хакер, которого так же зовут “Взломщик (cracker)” – это тот, кто использует эти слабости для вымогательства или собственного блага.
Эти два вида хакеров могут использовать одинаковый набор инструментов и, в общем, пытаются попасть в такие места, куда обычный пользователь не может попасть. Но белые хакеры делают это с разрешением, и в интересах усиления защиты, а не уничтожения её. Черные хакеры – плохие ребята.
Вот некоторые примеры наиболее распространённых атаках, которые используют слабости в защите: Внедрение SQL-кода и межсайтовый скриптинг XXS.
SQL атаки
SQL-инъекция (SQLi) - это тип инъекционной атаки, которая позволяет выполнять вредоносные SQL команды, для получения данных или вывода из строя приложения. По сути, злоумышленники могут отправлять команды SQL, которые влияют на ваше приложение, через некоторые входные данные на вашем сайте, например, поле поиска, которое извлекает результаты из вашей базы данных. Сайты, закодированные на PHP, могут быть особенно восприимчивы к ним, и успешная SQL-атака может быть разрушительной для программного обеспечения, которое полагается на базу данных (например, ваша таблица пользователей теперь представляет собой пустое место).
Вы можете проверить свой собственный сайт, чтобы увидеть, насколько он восприимчив к такого рода атакам. (Пожалуйста, тестируйте только те сайты, которыми вы владеете, так как запуск SQL-кодов там, где у вас нет разрешения на это, может быть незаконным в вашем регионе; и определенно, не очень смешно.) Следующие полезные нагрузки могут использоваться для тестов:
' OR 1='1 оценивается как константа true, и в случае успеха возвращает все строки в таблице
' AND 0='1 оценивается как константа false, и в случае успеха не возвращает строк.
К счастью, есть способы ослабить атаки SQL-кода, и все они сводятся к одной основной концепции: не доверяйте вводимым пользователем данным.
Смягчение последствий SQL-кодов.
Чтобы эффективно сдержать атаки, разработчики должны запретить пользователям успешно отправлять необработанные SQL-команды в любую часть сайта.
Некоторые фреймворки сделают большую часть тяжелой работы за вас. Например, Django реализует концепцию объектно-реляционного отображения, или ORM с использованием наборов запросов. Мы будем рассматривать их в качестве функций-оболочек, которые помогают вашему приложению запрашивать базу данных с помощью предопределенных методов, избегая использование необработанного SQL.
Однако возможность использовать фреймворк никогда не является гарантией. Когда мы имеем дело непосредственно с базой данных, существуют и другие методы, которые мы можем использовать, чтобы безопасно абстрагировать наши SQL-запросы от пользовательского ввода, хотя они различаются по эффективности. Они представлены по порядку от более к менее важному:
Подготовленные операторы с переменной привязкой (или параметризованные запросы)
Хранимые процедуры
Белый список или экранирование пользовательского ввода
Если вы хотите реализовать вышеприведенные методы, то эти шпаргалки - отличная отправная точка для более глубокого изучения. Достаточно сказать, что использование этих методов для получения данных вместо использования необработанных SQL-запросов помогает свести к минимуму вероятность того, что SQL будет обрабатываться любой частью вашего приложения, которая принимает входные данные от пользователей, тем самым смягчая атаки SQL-кодов.
Межсайтовые скриптовые атаки (XSS)
Если вы являетесь хакером, то JavaScript - это в значительной степени ваш лучший друг. Правильные команды будут делать все, что может сделать обычный пользователь (и даже некоторые вещи, которые он не должен делать) на веб-странице, иногда без какого-либо взаимодействия со стороны реального пользователя.
Межсайтовые скриптовые атаки, или XSS, происходят, когда код JavaScript вводится на веб-страницу и изменяет ее поведение. Его последствия могут варьироваться от появления неприятных шуток до более серьезных обходов аутентификации или кражи учетных данных.
XSS может происходить на сервере или на стороне клиента и, как правило, поставляется в трех вариантах: DOM (Document Object Model - объектная модель документа) на основе хранимых и отображаемых XSS. Различия сводятся к тому, где полезная нагрузка атаки вводится в приложение.
XSS на основе DOM
XSS на основе DOM возникает, когда полезная нагрузка JavaScript влияет на структуру, поведение или содержимое веб-страницы, загруженной пользователем в свой браузер. Они чаще всего выполняются через измененные URL-адреса, например, в фишинговых письмах.
Чтобы увидеть, насколько легко было бы для введенного JavaScript манипулировать страницей, мы можем создать рабочий пример с веб-страницей HTML. Попробуйте создать файл в локальной системе под названием xss-test.html (или любым другим) со следующим кодом HTML и JavaScript:
<html>
<head>
<title>My XSS Example</title>
</head>
<body>
<h1 id="greeting">Hello there!</h1>
<script>
var name = new URLSearchParams(document.location.search).get('name');
if (name !== 'null') {
document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
}
</script>
</h1>
</html>
На этой веб-странице будет отображаться заголовок "Hello!” если только он не получает параметр URL из строки запроса со значением name. Чтобы увидеть работу скрипта, откройте страницу в браузере с добавленным параметром URL, например:
file:///path/to/file/xss-test.html?name=Victoria
Наша небезопасная страница принимает значение параметра URL для имени и отображает его в DOM. Страница ожидает, что значение будет хорошей дружественной строкой, но что, если мы изменим его на что-то другое? Поскольку страница принадлежит нам и существует только в нашей локальной системе, мы можем тестировать ее сколько угодно. Что произойдет, если мы изменим параметр name, скажем, на:
<img+src+onerror=alert("pwned")>
Это всего лишь один пример, который демонстрирует, как может быть выполнена атака XSS. Смешные всплывающие оповещения могут быть забавными, но JavaScript может принести много вреда, в том числе помогая злоумышленникам украсть пароли и личную информацию.
Хранимые и отраженные XSS
Хранимые (stored) XSS возникают, когда полезная нагрузка атаки хранится на сервере, например, в базе данных. Атака влияет на жертву всякий раз, когда эти сохраненные данные извлекаются и отображаются в браузере.
Например, вместо того чтобы использовать строку URL-запроса, злоумышленник может обновить свою страницу профиля на социальном сайте, чтобы внедрить скрытый сценарий, скажем, в раздел “Обо мне”. Сценарий, неправильно сохраненный на сервере сайта, будет успешно выполняться всё время, пока другой пользователь просматривает профиль злоумышленника.
Одним из самых известных примеров этого является червь Samy, который практически захватил MySpace в 2005 году. Он распространялся путем отправки HTTP-запросов, которые копировали его на страницу профиля жертвы всякий раз, когда просматривался зараженный профиль. Всего за 20 часов он распространился на более чем миллион пользователей.
Отраженные (reflected) XSS аналогично возникают, когда введенные данные перемещаются на сервер, однако вредоносный код не сохраняется в базе данных. Вместо этого он немедленно возвращается в браузер веб-приложением.
Подобная атака может быть осуществлена путем заманивания жертвы для перехода по вредоносной ссылке, которая отправляет запрос на сервер уязвимого веб-сайта. Затем сервер отправит ответ злоумышленнику, а также жертве, что может привести к тому, что злоумышленник сможет получить пароли или совершить действия, которые якобы исходят от жертвы.
Ослабление XSS
Во всех этих случаях XSS могут быть сдержаны с помощью двух ключевых стратегий: проверка полей формы и предотвращение прямого ввода данных пользователем на веб-странице.
Проверка полей формы
Фреймворки снова могут нам помочь, когда речь заходит о том, чтобы убедиться, что представленные пользователем формы находятся в актуальном состоянии. Один из примеров - встроенные классы полей Django, которые предоставляют поля, проверяющие некоторые часто используемые типы, а также задают нормальные значения по умолчанию.
Например, поле электронной почты Django использует набор правил, чтобы определить, является ли предоставленный ввод действительным письмом. Если отправленная строка содержит символы, которые обычно не присутствуют в адресах электронной почты, или если она не имитирует общий формат адреса электронной почты, то Django не будет считать это поле допустимым и форма не будет отправлена.
Если вы не можете полагаться на фреймворк, можете реализовать вашу собственную проверку входных данных. Это можно сделать с помощью нескольких различных методов, включая преобразование типа, например, гарантируя, что число имеет тип int(); проверка минимальных и максимальных значений диапазона для чисел и длин строк; использование заранее определенного массива вариантов, который позволяет избежать произвольного ввода, например, месяцев года; и проверка данных на соответствие строгим регулярным формулировкам.
К счастью, нам не нужно начинать все с нуля. Помогут доступные ресурсы с открытым исходным кодом, такой как валидация репозитория регулярных выражений OWASP, который предоставляет шаблоны для сопоставления их с некоторыми распространенными формами данных. Многие языки программирования предлагают библиотеки проверки, специфичные для их синтаксиса, и мы можем найти множество таких библиотек на GitHub.
Хотя это и может показаться утомительным, правильно реализованная проверка ввода может защитить наше приложение от восприимчивости к XSS.
Предотвращение прямого ввода данных
Элементы приложения, которые непосредственно возвращают пользовательский ввод в браузер, при обычной проверке могут быть неочевидны. Мы можем определить области приложения, которые могут быть подвержены риску, изучив несколько вопросов:
Как происходит поток данных через приложение?
Что ожидает пользователь, когда он взаимодействует с этими входными данными?
Где на нашей странице появляются данные? Становятся ли они встроенными в строку или атрибут?
Вот некоторые примеры полезных нагрузок, с которыми мы можем поиграть, чтобы проверить входные данные на нашем сайте (опять же, только на нашем собственном сайте!). Успешное выполнение любого из этих образцов может указывать на возможную уязвимость к XSS из-за прямого ввода данных.
"><h1>test</h1>
'+alert(1)+'
"onmouserover="alert(1)
http://"onmouseover="alert(1)
Как правило, если вы можете обойти прямой ввод данных, сделайте это. Кроме того, убедитесь, что вы полностью понимаете эффективность выбранных методов; например, использование innerText вместо innerHTML в JavaScript гарантирует, что содержимое будет задано как обычный текст вместо (потенциально уязвимого) HTML.
Аккуратнее с вводом!
Разработчики программного обеспечения явно находятся в невыгодном положении, когда речь заходит о конкуренции с черными хакерами. Несмотря на всю проделанную работу по защитите каждого ввода, который потенциально может скомпрометировать наше приложение, злоумышленнику достаточно только найти тот, который мы пропустили. Это все равно что установить засовы на всех дверях, но оставить окно открытым!
Однако, научившись мыслить в том же ключе, что и злоумышленник, мы можем лучше подготовить наше программное обеспечение к противостоянию плохим парням. Как бы ни было интересно добавлять функции как можно быстрее, мы избежим большого количества долгов по кибербезопасности, если заранее продумаем поток нашего приложения, проследим за данными и обратим внимание на наши входные данные.
JIT-компиляция – это метод повышения производительности интерпретируемых программ. JIT расшифровывается как Just-in-time. Во время выполнения программа может быть скомпилирована в машинный код для повышения ее производительности. Также этот метод известен как динамическая компиляция.
Динамическая компиляция имеет несколько преимуществ перед статической. При запуске приложений на JAVA или C# среда выполнения может профилировать приложение во время его исполнения. Это позволяет создавать более оптимизированный код. Если поведение приложения меняется во время его исполнения, то среда выполнения может перекомпилировать код.
Есть некоторые недостатки, заключающиеся в задержках при запуске или непроизводительных издержках при компиляции во время выполнения. Чтобы ограничить эти издержки, многие JIT-компиляторы компилируют только пути кода, которые часто используются.
Обзор
Традиционно существует два метода преобразования исходного кода в форму, которую можно запустить на платформе. Статистическая компиляция преобразует код в язык для конкретной платформы. Интерпретатор непосредственно выполняет исходный код.
JIT-компиляция пытается использовать преимущества обоих. В то время как выполняется интерпретируемая программа, JIT-компилятор определяет участки часто используемого кода и компилирует его в машинный код. В зависимости от компилятора это можно сделать для метода или меньшего участка кода.
Впервые динамическая компиляция была описана в статье о языке LISP Дж. Маккарти в 1960 году.
Компиляция на лету, JIT или динамическая компиляция – это компиляция, которая выполняется непосредственно во время исполнения программы, а не до этого. Что в этот момент происходит? Перевод в машинный код. Преимущества JIT-компиляции заключаются в том, что поскольку компиляция происходит во время выполнения, то JIT-компилятор имеет доступ к динамической информации времени выполнения, а это в свою очередь позволяет ему оптимизировать процесс (например, встраивать функции).
Что важно понимать, когда речь идет о JIT-компиляции? Она скомпилирует байт-код в инструкции машинного кода работающего компьютера. Это означает, что полученный машинный код оптимизирован для архитектуры процессора конкретного компьютера.
В качестве примеров JIT-компиляторов можно привести JVM (Java Virtual Machine - виртуальная машина Java) на Java и CLR (Common Language Runtime – общеязыковая исполняющая среда) на C#.
История
Изначально компилятор отвечал за преобразование языка высокого уровня (выше, чем ассемблер) в объектный код (машинные инструкции), который затем должен был быть связан (линкером) с исполняемой программой.
В какой-то момент эволюции языков компиляторы начали компилировать язык высокого уровня в псевдокод, который затем интерпретировался (интерпретатором) для запуска программы. Это исключило объектный код и исполняемые программы и позволило перенести эти языки на несколько операционных систем и аппаратных платформ. Одним из первых был Pascal (который скомпилирован в P-Code); более современными примерами являются Java и C#. Со временем термин P-Code был заменен на байт-код, поскольку большинство псевдоопераций имеют длину в один байт.
JIT-компилятор – это функция интерпретатора, которая вместо интерпретации байт-кода при каждом вызове компилирует байт-код в инструкции машинного кода работающей машины, а затем вызывает этот объектный код. В идеальном варианте эффективность выполнения объектного кода должна превзойти неэффективность перекомпиляции программы при каждом ее запуске.
Обычный сценарий
Исходный код полностью преобразуется в машинный код.
JIT-сценарий
Исходный код преобразуется в структуру на языке ассемблера, например, IL (промежуточный язык) для C#, ByteCode для Java.
Промежуточный код преобразуется в машинный только тогда, когда приложение нуждается в том, чтобы необходимые коды были преобразованы в машинный код.
JIT или не JIT
При JIT-компиляции не весь код преобразуется в машинный код. Для начала преобразуется только необходимая часть кода. Затем, если вызываемый метод или выполняемые функции находятся не в виде машинного кода, то они тоже будут преобразованы в машинный код. Это снижает нагрузку на ЦП. Поскольку машинный код будет генерироваться во время выполнения, то JIT-компилятор создаст машинный код, оптимизированный для запуска архитектуры ЦП машины.
Ниже приведены некоторые примеры JIT-компиляторов:
Java: JVM (Java Virtual Machine – виртуальная машина Java)
C#: CLR (Common Language Runtime – общеязыковая исполняющая среда)
Android: DVM (Dalvik Virtual Machine – виртуальная машина Dalvik) или ART (Android RunTime – среда выполнения Android-приложений) в новых версиях
Виртуальная машина Java (JVM) выполняет байт-код и ведет подсчет времени выполнения функции. Если это значение превышает предустановленный порог, то JIT-компилятор компилирует код в машинный код, который в дальнейшем может быть выполнен непосредственно процессором (в отличие от случая, когда javac компилирует код в байт-код, а затем интерпретатор интерпретирует этот байт-код построчно, переводя его в машинный код, и выполняет его).
Кроме того, при следующем вычислении функции тот же скомпилированный код выполняется снова, в отличие от обычной интерпретации, когда код повторно интерпретируется построчно. Это значительно ускоряет процесс выполнения программы.
В сегодняшней статье мы еще раз коснемся сетей ISDN (Integrated Services for Digital Network). Как известно, ISDN – это набор протоколов, который объединяет цифровую телефонию и сервисы передачи данных. Основная идея ISDN – преобразование телефонной сети в цифровую форму для передачи аудио, видео и текстовых сообщений через существующие телефонные линии. Конечная цель ISDN – формирования Глобальной сети (WAN), которая обеспечивает универсальное непрерывное соединение через цифровую среду. В ISDN существует два типа интерфейсов для организации доступа к ресурсам сети – PRI (Primary Rate Interface) и BRI Basic Rate Interface, котором и пойдет речь.
Итак, BRI – это тип интерфейса в сети ISDN, обеспечивающий предоставление двух основных цифровых каналов (ОЦК) по 64 кбит/с каждый, именуемых также каналами “B”, и однополосных канал, выделенный для передачи цифровой сигнализации со скоростью 16 кбит/с, который называют каналом “D”. Наиболее распространенный тип цифровой сигнализации, применяемый в сетях ISDN - DSS1 (Euro ISDN). Таким образом, интерфейс доступа BRI идентифицируют как 2B+D, а максимальная скорость передачи по данному интерфейсу составляет 128 + 16 = 144 кбит/с. Стоит отметить, что интерфейс BRI предназначен в первую очередь для использования в абонентских линиях, аналогичных тем, которые уже давно используются для голосовой телефонной связи. Предоставляется в основном для абонентов жилищного сектора и малых офисов.
С физической точки зрения, интерфейс BRI делится на несколько частей.
1) Прокладка кабеля непосредственно от ISDN терминала до сетевого окончания NT (Network Termination) - S/T интерфейс (S0)
Данный процесс описывается в рекомендации I.430, разработанной Международным Союзом Электросвязи (ITU). Интерфейс S/T использует 4 провода, одна пара выделяется под передачу (uplink), а другая под прием (downlink). Осуществляет полнодуплексный режим взаимодействия. Рекомендация I.430 описывает определение 48-битных пакетов, включая 16 бит от канала B1, 16 бит от канала B2, 4 бит от канала D, а также 12 бит, использующихся для нужд синхронизации. Эти пакеты отсылаются с частотой 4 КГц, в результате чего, общий битрейт 192 кбит/c, обеспечивает скорость передачи, перечисленных выше данных, с максимально возможной пропускной способностью – 144 кбит/c. Интерфейс S0 позволяет организовать соединение типа точка-точка или точка – множество точек. Максимальная длина – 900 м (точка-точка), 300 м (точка – множество точек)
2) Передача от сетевого окончания NT до центрального офиса – U интерфейс
Интерфейс U использует два провода. Общий битрейт – 160 кбит/с; пропускная способность 144 кбит/с, 12 кбит/c выделяется для нужд синхронизации и 4 кбит/с для сигналов обслуживания. Сигналы от U интерфейса в точке отправки кодируются двумя способами модуляции, исходя их используемых стандартов в той или иной стране. Так в Северной Америке, Италии и Швейцарии используется механизм 2B1Q, и 4B3T в остальных странах. В зависимости от применяемой длины кабеля существует три разновидности U интерфейсов – UpN, Up0 и Uk0 . Интерфейс Uk0 использует один пару проводов с эхоподавлением для длинного кабеля последней мили между АТС и сетевым окончанием NT . Максимальная длина этого промежутка BRI составляет от 4 до 8 км.