# Competent

• Attack Patterns and Defence Mechanisms:

  • Buffer Overflow
  • SQL/Code Injection
  • Authentication Attacks
  • Session Management Attacks
  • Access Control Attacks

• Attacking Users:

  • Cross-Site Request Forgery (XSRF)
  • Cross-Site Script Inclusion (XSSI)
  • Cross-Site Scripting (XSS)

• Cryptography Concepts:

  • Symmetric Key Cryptography
  • Asymmetric Key Cryptography

• Transport Layer Security (TLS, SSL)

# Attack Patterns and Defence Mechanisms:

# Buffer Overflow

A buffer is an area of memory that can be used to store user input. Buffers often have some fixed maximum size. If the user provides more input than can fit into the buffer, the extra input might end up in unexpected places in memory, and the buffer is said to overflow.

A buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. A buffer overflow, or buffer overrun, occurs when more data is put into a fixed-length buffer than the buffer can handle. The extra information, which has to go somewhere, can overflow into adjacent memory space, corrupting or overwriting the data held in that space. This overflow usually results in a system crash, but it also creates the opportunity for an attacker to run arbitrary code or manipulate the coding errors to prompt malicious actions.

Many programming languages are prone to buffer overflow attacks. However, the extent of such attacks varies depending on the language used to write the vulnerable program. For instance, code written in Perl and JavaScript is generally not susceptible to buffer overflows. However, a buffer overflow in a program written in C, C++, Fortran or Assembly could allow the attacker to fully compromise the targeted system.

A buffer is a temporary area for data storage. When more data (than was originally allocated to be stored) gets placed by a program or system process, the extra data overflows. It causes some of that data to leak out into other buffers, which can corrupt or overwrite whatever data they were holding.

In a buffer-overflow attack, the extra data sometimes holds specific instructions for actions intended by a hacker or malicious user; for example, the data could trigger a response that damages files, changes data or unveils private information.

Attacker would use a buffer-overflow exploit to take advantage of a program that is waiting on a user’s input. There are two types of buffer overflows: stack-based and heap-based. Heap-based, which are difficult to execute and the least common of the two, attack an application by flooding the memory space reserved for a program. Stack-based buffer overflows, which are more common among attackers, exploit applications and programs by using what is known as a stack: memory space used to store user input.

Buffer Overflow Causes

Coding errors are typically the cause of buffer overflow. Common application development mistakes that can lead to buffer overflow include failing to allocate large enough buffers and neglecting to check for overflow problems. These mistakes are especially problematic with C/C++, which does not have built-in protection against buffer overflows. Consequently, C/C++ applications are often targets of buffer overflow attacks.

# SQL/Code Injection

SQL Injection (SQLi) is a type of an injection attack that makes it possible to execute malicious SQL statements. These statements control a database server behind a web application. Attackers can use SQL Injection vulnerabilities to bypass application security measures. They can go around authentication and authorization of a web page or web application and retrieve the content of the entire SQL database. They can also use SQL Injection to add, modify, and delete records in the database.

An SQL Injection vulnerability may affect any website or web application that uses an SQL database such as MySQL, Oracle, SQL Server, or others. Criminals may use it to gain unauthorized access to your sensitive data: customer information, personal data, trade secrets, intellectual property, and more. SQL Injection attacks are one of the oldest, most prevalent, and most dangerous web application vulnerabilities.

Programs can use an SQL statement to specify what data they want the database to retrieve or update. Given an SQL statement, the database determines how to efficiently obtain or modify the relevant data, and returns the results to the program. An SQL injection attack is possible if an application uses data that can be controlled by an attacker as part of an SQL query. The attacker may be able to submit specially crafted input, such that the query that is sent to the database is interpreted by the database differently from what the programmer intended.

Example https://www.deliver-me-pizza.com/show_orders?month=10

attack (query_param):

https://www.deliver-me-pizza.com/show_orders?month=0%20OR%201%3D1

CGI parameters are transferred from the browser in so-called URL-encoded form, where meta-characters (in particular, blanks, percent signs, ampersands, and equal signs) are replaced with the percent sign followed by the character’s ASCII code in hexadecimal notation (Berners-Lee, Fielding, and Masinter 2005). The web application reverses this encoding after extracting a CGI parameter from the request. Thus, request.getParameter("month") returns the string 0 OR 1=1

Since 1=1 always evaluates to true, this condition is logically equivalent to true. Hence, the SQL query in fact returns the entire contents of the orders table, which the application would dutifully transcribe into a (quite large) HTML table, and return to the user. What happened? The (malicious) user supplied a parameter that, once inserted into the SQL query string, actually altered the meaning of the query! In this case, he was able to modify the logical structure of the WHERE clause, causing more rows to be retrieved from the database than he would legitimately be authorized to see; in particular, he received rows where the userid column is not equal to his user-id.

Defending

• User input should never be trusted - It must always be sanitized before it is used in dynamic SQL statements.
• Stored procedures – these can encapsulate the SQL statements and treat all input as parameters.
• Prepared statements –prepared statements to work by creating the SQL statement first then treating all submitted user data as parameters. This has no effect on the syntax of the SQL statement.
• Regular expressions –these can be used to detect potential harmful code and remove it before executing the SQL statements.
• Database connection user access rights –only necessary access rights should be given to accounts used to connect to the database. This can help reduce what the SQL statements can perform on the server.
• Error messages –these should not reveal sensitive information and where exactly an error occurred. Simple custom error messages such as “Sorry, we are experiencing technical errors. The technical team has been contacted. Please try again later” can be used instead of display the SQL statements that caused the error.

# Authentication Attacks

# Authentication Technologies

• HTML forms-based authentication
• Multi-factor mechanisms, such as those combining passwords and physical tokens
• Client SSL certificates and/or smartcards
• HTTP basic and digest authentication
• Windows-integrated authentication using NTLM or Kerberos
• Authentication services

By far the most common authentication mechanism employed by web applications uses HTML forms to capture a username and password and submit these to the application. This mechanism accounts for well over 90% of applications you are likely to encounter on the Internet.

# Design Flaws in Authentication Mechanisms

• Bad Passwords
• Brute-Forcible Login
• Verbose Failure Messages
• Vulnerable Transmission of Credentials
• Password Change Functionality
• Forgotten Password Functionality
• "Remember Me" functionality by cookies
• Incomplete Validation of Credentials
• Non-Unique Usernames
• Insecure Distribution of Credentials

# Implementation Flaws in Authentication

• Fail-Open Login Mechanisms
• Defects in Multistage Login Mechanisms
• Insecure Storage of Credentials

# Securing Authentication

• Use Strong Credentials
• Handle Credentials Secretively
• Validate Credentials Properly (password should be validation at fool)

# Session Management Attacks

The HTTP protocol is essentially stateless. It is based on a simple requestresponse model, in which each pair of messages represents an independent transaction. The protocol itself contains no mechanism for linking together the series of requests made by one particular user and distinguishing these from all of the other requests received by the web server. In the early days of the Web, there was no need for any such mechanism: web sites were used to publish static HTML pages for anyone to view

The most obvious use of sessions is in applications that support logging in. After entering your username and password, you can go ahead and use the application as the user whose credentials you have entered, until such time as you log out or the session expires due to inactivity.

The vulnerabilities that exist in session management mechanisms largely fall into two categories:

• Weaknesses in the generation of session tokens.
  • Meaningful Tokens
  • Predictable Tokens
  • Time Dependency
  • Weak Random Number Generation
• Weaknesses in the handling of session tokens throughout their lifecycle
  • Disclosure of Tokens on the Network
  • Disclosure of Tokens in Logs
  • Vulnerable Mapping of Tokens to Sessions
  • Client Exposure to Token Hijacking
  • Liberal Cookie Scope

# Alternatives to Sessions

• HTTP authentication — Applications using the various HTTP-based authentication technologies (basic, digest, NTLM, etc.) sometimes avoid the need to use sessions. With HTTP authentication, the client component interacts with the authentication mechanism directly viabrowser, using HTTP headers, and not via application-specific code contained within any individual page. Once a user has entered his credentials into a browser dialog, the browser effectively resubmits these credentials (or reperforms any required handshake) with every subsequent request to the same server.

• Sessionless state mechanisms — Some applications do not issue session tokens in order to manage the state of a user’s interaction with the application but rather transmit all data required to manage that state via the client, usually in a cookie or a hidden form field

# Securing Session Management

• Generate Strong Tokens
  • use an extremely large set of possible values
  • contain a strong source of pseudo-randomness, ensuring an even and unpredictable spread of tokens across the range of possible values.
• Protect Tokens throughout Their Lifecycle
  • The token should only ever be transmitted over HTTPS
  • Session tokens should never be transmitted in the URL
  • Logout functionality should be implemented
  • Session expiration should be implemented after a suitable period of inactivity (e.g., 10 minutes)
  • Concurrent logins should be prevented
  • If the application contains any administrative or diagnostic functionality that enables session tokens to be viewed, this functionality should be robustly defended against unauthorized access
  • The domain and path scope of an application’s session cookies should be set as restrictively as possible
  • The application’s codebase should be rigorously audited to identify and remove any cross-site scripting vulnerabilities
  • Log, Monitor, and Alert
    • The application should monitor requests that contain invalid tokens.

Per-Page Tokens

Finer-grained control over sessions can be achieved, and many kinds of session attacks made more difficult or impossible, by using per-page tokens in addition to session tokens. Here, a new page token is created every time a user requests an application page (as opposed to an image, for example) and is passed to the client in a cookie or a hidden field of an HTML form. Each time the user makes a request, the page token is validated against the last value issued, in addition to the normal validation of the main session token. In the case of a non-match, the entire session is terminated. Many of the most security-critical web applications on the Internet, such as online banks, employ per-page tokens to provide increased protection for their session management mechanism,

# Access Control Attacks

Access controls can be divided into two broad categories: vertical and horizontal.

Vertical access controls allow different types of users to access different parts of the application’s functionality. In the simplest case, this typically involves a division between ordinary users and administrators. In more complex cases, vertical access controls may involve fine-grained user roles granting access to specific functions, with each user being allocated to a single role, or a combination of different roles.

Horizontal access controls allow users to access a certain subset of a wider range of resources of the same type. For example, a web mail application may allow you to read your email but no one else’s; an online bank may let you transfer money out of your account only; and a workflow application may allow you to update tasks assigned to you but only read tasks assigned to other people.

Access controls are broken if any user is able to access functionality or resources for which he is not authorized. There are two main types of attack against access controls, corresponding to the two categories of control:

• Vertical privilege escalation occurs when a user can perform functions that their assigned role does not permit them to. For example, if an ordinary user can perform administrative functions or a clerk is able to pay invoices of any size, then access controls are broken.

• Horizontal privilege escalation occurs when a user can view or modify resources to which he is not entitled. For example, if you can use a web mail application to read other people’s email, or if a payment clerk can process invoices for an organizational unit other than his own, then access controls are broken

# Completely Unprotected Functionality

In many cases of broken access controls, sensitive functionality and resources can be accessed by anyone who knows the relevant URL.

# Identifier-Based Functions

When a function of an application is used to gain access to a specific resource, it is very common to see an identifier for the requested resource being passed to the server in a request parameter, either within the URL query string or the body of a POST request.

# Multistage Functions

It is common to encounter applications in which efforts have been made to protect this kind of sensitive functionality from unauthorized access but where the access controls employed are broken because of flawed assumptions about the ways in which the functionality will be used.

# Static Files

In the majority of cases, users gain access to protected functionality and resources by issuing requests to dynamic pages that execute on the server. It is the responsibility of each such page to perform suitable access control checks, and confirm that the user has the relevant privileges to perform the action that they are attempting. However, in some cases, requests for protected resources are made directly to the static resources themselves, which are located within the web root of the server. For example, an online publisher may allow users to browse its book catalog and purchase ebooks for download.

# Insecure Access Control Methods

https://wahh-app.com/login/home.jsp?admin=true

Once all accessible functionality has been enumerated, it is necessary to test whether per-user segregation of access to resources is being correctly enforced. In every instance where the application grants users access to a subset of a wider range of resources of the same type (such as documents, orders, emails, and personal details), there may be opportunities for one user to gain unauthorized access to other resources.

# Securing Access Control

Access controls are one of the easiest areas of web application security to understand, although a well-informed, thorough methodology must be carefully applied when implementing them.

First, there are several obvious pitfalls to avoid. These usually arise from ignorance about the essential requirements of effective access control or flawed assumptions about the kinds of requests that users will make and against which the application needs to defend itself:

• Do not rely on users’ ignorance of application URLs or the identifiers used to specify application resources, such as account numbers and document IDs. Explicitly assume that users know every application URL and identifier, and ensure that the application’s access controls alone are sufficient to prevent unauthorized access.
• Do not trust any user-submitted parameters to signify access rights (such as admin=true).
• Do not assume that users will access application pages in the intended sequence. Do not assume that because users cannot access the Edit Users page, they will not be able to reach the Edit User X page that is linked from it.
• Do not trust the user not to tamper with any data that is transmitted via the client. If some user-submitted data has been validated and is then transmitted via the client, do not rely upon the retransmitted value without revalidation.

The following represents a best-practice approach to implementing effective access controls within web applications:

• Explicitly evaluate and document the access control requirements for every unit of application functionality. This needs to include both who can legitimately use the function and what resources individual users may access via the function.
• Drive all access control decisions from the user’s session.
• Use a central application component to check access controls.
• Process every single client request via this component, to validate that the user making the request is permitted to access the functionality and resources being requested.
• Use programmatic techniques to ensure that there are no exceptions to the previous point. An effective approach is to mandate that every application page must implement an interface that is queried by the central access control mechanism. By forcing developers to explicitly code access control logic into every page, there can be no excuse for omissions.
• For particularly sensitive functionality, such as administrative pages, you can further restrict access by IP address, to ensure that only users from a specific network range are able to access the functionality, regardless of their login status.
• If static content needs to be protected, there are two methods of providing access control. First, static files can be accessed indirectly by passing a file name to a dynamic server-side page which implements relevant access control logic. Second, direct access to static files can be controlled using HTTP authentication or other features of the application server to wrap the incoming request and check the permissions for the resource before granting access.
• Identifiers specifying which resource a user wishes to access are vulnerable to tampering whenever they are transmitted via the client. The server should trust only the integrity of server-side data. Any time these identifiers are transmitted via the client, they need to be revalidated to ensure the user is authorized to access the requested resource.
• For security-critical application functions such as the creation of a new bill payee in a banking application, consider implementing pertransaction reauthentication and dual authorization to provide additional assurance that the function is not being used by an unauthorized party. This will also mitigate the consequences of other possible attacks, such as session hijacking.
• Log every event where sensitive data is accessed or a sensitive action is performed. These logs will enable potential access control breaches to be detected and investigated.

# Attacking Users

# Cross-Site Request Forgery (XSRF)

Какие это действия – отправка ли сообщений, перевод денег со счёта на счёт или смена паролей – зависят от сайта

«Классический» сценарий атаки таков:

• Вася является залогиненным на сайт, допустим, mail.com. У него есть сессия в куках.
• Вася попал на «злую страницу», например хакер пригласил его сделать это письмом или как-то иначе.
• На злой странице находится форма такого вида:

  <form action="http://mail.com/send" method="POST">
  <input type="hidden" name="message" value="Сообщение">
  ...
  </form>
  

• При заходе на злую страницу JavaScript вызывает form.submit, отправляя таким образом форму на mail.com.
• Сайт mail.com проверяет куки, видит, что посетитель авторизован и обрабатывает форму. В данном примере форма предполагает посылку сообщения.
• Итог атаки – Вася, зайдя на злую страницу, ненароком отправил письмо от своего имени. Содержимое письма сформировано хакером.

Защита

В примере выше атака использовала слабое звено авторизации. Куки позволяют сайту mail.com проверить, что пришёл именно Вася, но ничего не говорят про данные, которые он отправляет. Иначе говоря, куки не гарантируют, что форму создал именно Вася. Они только удостоверяют личность, но не данные.

Итого

• CSRF-атака – это когда «злая страница» отправляет форму или запрос на сайт, где посетитель, предположительно, залогинен.
• Если сайт проверяет только куки, то он такую форму принимает. А делать это не следует, так как её сгенерировал злой хакер.
• Для защиты от атаки формы, которые генерирует mail.com, подписываются специальным токеном. Можно не все формы, а только те, которые осуществляют действия от имени посетителя, то есть могут служить объектом атаки.
• Для подписи XMLHttpRequest токен дополнительно записывается в куку. Тогда JavaScript с домена mail.com сможет прочитать её и добавить в заголовок, а сервер – проверить, что заголовок есть и содержит корректный токен.
• Динамически сгенерированные формы подписываются аналогично: токен из куки добавляется как URL-параметр или дополнительное поле.

# Cross-Site Script Inclusion (XSSI)

XSSI attack can happen in the following two ways:

• Attacker's website invokes JSON API using a script tag: Users log into the actual website, which results in the website setting cookie information for further interaction. Users are, then, lured to open attacker's website. As the page loads, the browser invokes the JSON API of the actual website by sending users' cookie information. This JSON API is embedded within script tag. The actual website sends back JSON data and this results in an XSSI attack. Note, that this attack works on older browsers by overriding native JS object constructors and including JSON API as part of a script tag.

• Attackers website accesses dynamically generated JavaScript files: Often, it is seen that one or more JavaScript files are generated dynamically based on users' session state and sent back to client as the page loads. The dynamic generation of the scripts from the website based on user session/cookie information results in the leakage of user related information such as user profile data (such as user ID, email), CSRF or auth tokens, and so on, as part of the script data.

1. Users log into the website, which results in the website setting cookies for further message exchanges between user's browser and the website.
2. Attackers lure the users to visit their website through techniques such as clicking a URL in an email, and so on.
3. User visit the attackers' website.
4. Attacker's website loads the script/JSON from original website by sending users' cookie information.
5. As the script/JSON is dynamically generated based on users' cookie information, this results in leakage of users' information to the attacker's website.

# Cross-Site Scripting (XSS)

XSS это возможность злоумышленника определенным образом интегрировать в страницу сайта-жертвы скрипт, который будет выполнен при ее посещении.

Существует два типа XSS уязвимостей — пассивная и активная.

Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.

При пассивной уязвимости нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке. Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника.

Кража Cookies - это наиболее часто приводимый пример XSS-атаки. В Cookies сайты иногда хранят какую-нибудь ценную информацию (иногда даже логин и пароль (или его хэш) пользователя), но самой опасной является кража активной сессии, поэтому не забываем нажимать ссылку «Выход» на сайтах, даже если это домашний компьютер. К счастью, на большинстве ресурсов время жизни сессии ограничено.

Кража данных из форм ищем форму через, например, getElementById и отслеживаем событие onsubmit. Теперь, перед отправкой формы, введенные данные отправляются также и на сервер злоумышленника. Этот тип атаки чем-то напоминает фишинг, только используется не поддельный сайт, а реальный, чем вызывается большее доверие жертвы.

Основная цель межсайтового скриптинга – кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.

Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.

<script>alert("cookie: "+document.cookie)</script>

# Cryptography Concepts

Криптосистема работает по определенной методологии (процедуре). Она состоит из : одного или более алгоритмов шифрования (математических формул); ключей, используемых этими алгоритмами шифрования; системы управления ключами; незашифрованного текста; и зашифрованного текста (шифртекста).

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

В этой методологии алгоритм шифрования объединяет ключ с текстом для создания шифртекста. Безопасность систем шифрования такого типа зависит от конфиденциальности ключа, используемого в алгоритме шифрования, а не от хранения в тайне самого алгоритма. Многие алгоритмы шифрования общедоступны и были хорошо проверены благодаря этому (например, DES).

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

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

Сообщение шифруется кем-то, кто владеет ключом в данный момент. Это может быть владелец ключа; но если система скомпрометирована, это может быть другой человек. Когда участники взаимодействия получают ключи, откуда они могут узнать, что эти ключи на самом деле были созданы и посланы уполномоченным на это лицом? Существуют две методологии с использованием ключей - симметричная (с секретным ключом) и асимметричная (с открытым ключом). Каждая методология использует свои собственные процедуры, свои способы распределения ключей, типы ключей и алгоритмы шифрования и расшифровки ключей.

# Symmetric Key Cryptography

Часто называется методологией с секретным ключом.

• DES (64-bit block cipher)
• Triple DES
• AES (A new encryption standard was needed since DES was too easily crackable via brute-force search, and Triple DES was too slow from a performance standpoint for many applications. AES is a replacement for DES and Triple DES that provides security with larger keys and faster execution time.
• RC4
• Steganography is the study of techniques for sending sensitive information that attempt to hide the fact that sensitive information is being sent at all. Steganographic techniques typically use a “covert channel” to send sensitive information from one party to another.

В этой методологии и для шифрования, и для расшифровки отправителем и получателем применяется один и тот же ключ, об использовании которого они договорились до начала взаимодействия. Если ключ не был скомпрометирован, то при расшифровке автоматически выполняется аутентификация отправителя, так как только отправитель имеет ключ, с помощью которого можно зашифровать информацию, и только получатель имеет ключ, с помощью которого можно расшифровать информацию. Так как отправитель и получатель - единственные люди, которые знают этот симметричный ключ, при компрометации ключа будет скомпрометировано только взаимодействие этих двух пользователей. Проблемой, которая будет актуальна и для других криптосистем, является вопрос о том, как безопасно распространять симметричные (секретные) ключи.

Алгоритмы симметричного шифрования используют ключи не очень большой длины и могут быстро шифровать большие объемы данных.

Порядок использования систем с симметричными ключами:

• Безопасно создается, распространяется и сохраняется симметричный секретный ключ.
• Отправитель создает электронную подпись с помощью расчета хэш-функции для текста и присоединения полученной строки к тексту
• Отправитель использует быстрый симметричный алгоритм шифрования-расшифровки вместе с секретным симметричным ключом к полученному пакету (тексту вместе с присоединенной электронной подписью) для получения зашифрованного текста. Неявно таким образом производится аутентификация, так как только отправитель знает симметричный секретный ключ и может зашифровать этот пакет. Только получатель знает симметричный секретный ключ и может расшифровать этот пакет.
• Отправитель передает зашифрованный текст. Симметричный секретный ключ никогда не передается по незащищенным каналам связи.
• Получатель использует тот же самый симметричный алгоритм шифрования-расшифровки вместе с тем же самым симметричным ключом (который уже есть у получателя) к зашифрованному тексту для восстановления исходного текста и электронной подписи. Его успешное восстановление аутентифицирует кого-то, кто знает секретный ключ.
• Получатель отделяет электронную подпись от текста.
• Получатель создает другую электронную подпись с помощью расчета хэш-функции для полученного текста.
• Получатель сравнивает две этих электронных подписи для проверки целостности сообщения (отсутствия его искажения)

Доступными сегодня средствами, в которых используется симметричная методология, являются:

• Kerberos, который был разработан для аутентификации доступа к ресурсам в сети, а не для верификации данных. Он использует центральную базу данных, в которой хранятся копии секретных ключей всех пользователей.
• Сети банкоматов (ATM Banking Networks). Эти системы являются оригинальными разработками владеющих ими банков и не продаются. В них также используются симметричные методологии.

# Asymmetric Key Cryptography

Часто называется методологией с открытым ключом

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

Создаются два взаимосвязанных асимметричных ключа. Один должен быть безопасно передан его владельцу, а другой - тому лицу, которое отвечает за хранение этих ключей (CA - сертификационному центру ключей), до начала их использования.

В этой методологии ключи для шифрования и расшифровки разные, хотя и создаются вместе. Один ключ делается известным всем, а другой держится в тайне. Хотя можно шифровать и расшифровывать обоими ключами, данные, зашифрованные одним ключом, могут быть расшифрованы только другим ключом.

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

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

В асимметричных криптосистемах важно, чтобы сеансовые и асимметричные ключи были сопоставимы в отношении уровня безопасности, который они обеспечивают. Если используется короткий сеансовый ключ ( например, 40-битовый DES), то не имеет значения, насколько велики асимметричные ключи. Хакеры будут атаковать не их, а сеансовые ключи. Асимметричные открытые ключи уязвимы к атакам прямым перебором отчасти из-за того, что их тяжело заменить. Если атакующий узнает секретный асимметричный ключ, то будет скомпрометирован не только текущее, но и все последующие взаимодействия между отправителем и получателем.

Порядок использования систем с асимметричными ключами:

• Безопасно создаются и распространяются асимметричные открытые и секретные ключи (см. раздел 2.2 ниже). Секретный асимметричный ключ передается его владельцу. Открытый асимметричный ключ хранится в базе данных X.500 и администрируется центром выдачи сертификатов (по-английски - Certification Authority или CA). Подразумевается, что пользователи должны верить, что в такой системе производится безопасное создание, распределение и администрирование ключами. Более того, если создатель ключей и лицо или система, администрирующие их, не одно и то же, то конечный пользователь должен верить, что создатель ключей на самом деле уничтожил их копию.
• Создается электронная подпись текста с помощью вычисления его хэш-функции. Полученное значение шифруется с использованием асимметричного секретного ключа отправителя, а затем полученная строка символов добавляется к передаваемому тексту (только отправитель может создать электронную подпись).
• Создается секретный симметричный ключ, который будет использоваться для шифрования только этого сообщения или сеанса взаимодействия (сеансовый ключ), затем при помощи симметричного алгоритма шифрования/расшифровки и этого ключа шифруется исходный текст вместе с добавленной к нему электронной подписью - получается зашифрованный текст (шифр-текст).
• Теперь нужно решить проблему с передачей сеансового ключа получателю сообщения.
• Отправитель должен иметь асимметричный открытый ключ центра выдачи сертификатов (CA). Перехват незашифрованных запросов на получение этого открытого ключа является распространенной формой атаки. Может существовать целая система сертификатов, подтверждающих подлинность открытого ключа CA. Стандарт X.509 описывает ряд методов для получения пользователями открытых ключей CA, но ни один из них не может полностью защитить от подмены открытого ключа CA, что наглядно доказывает, что нет такой системы, в которой можно было бы гарантировать подлинность открытого ключа CA.
• Отправитель запрашивает у CA асимметричный открытый ключ получателя сообщения. Этот процесс уязвим к атаке, в ходе которой атакующий вмешивается во взаимодействие между отправителем и получателем и может модифицировать трафик, передаваемый между ними. Поэтому открытый асимметричный ключ получателя "подписывается" CA. Это означает, что CA использовал свой асимметричный секретный ключ для шифрования асимметричного отркытого ключа получателя. Только CA знает асимметричный секретный ключ CA, поэтому есть гарантии того, что открытый асимметричный ключ получателя получен именно от CA.
• После получения асимметричный открытый ключ получателя расшифровывается с помощью асимметричного открытого ключа CA и алгоритма асимметричного шифрования/расшифровки. Естественно, предполагается, что CA не был скомпрометирован. Если же он оказывается скомпрометированным, то это выводит из строя всю сеть его пользователей. Поэтому можно и самому зашифровать открытые ключи других пользователей, но где уверенность в том, что они не скомпрометированы?
• Теперь шифруется сеансовый ключ с использованием асимметричного алгоритма шифрования-расшифровки и асимметричного ключа получателя (полученного от CA и расшифрованного).
• Зашифрованный сеансовый ключ присоединяется к зашифрованному тексту (который включает в себя также добавленную ранее электронную подпись).
• Весь полученный пакет данных (зашифрованный текст, в который входит помимо исходного текста его электронная подпись, и зашифрованный сеансовый ключ) передается получателю. Так как зашифрованный сеансовый ключ передается по незащищенной сети, он является очевидным объектом различных атак.
• Получатель выделяет зашифрованный сеансовый ключ из полученного пакета.
• Теперь получателю нужно решить проблему с расшифровкой сеансового ключа.
• Получатель должен иметь асимметричный открытый ключ центра выдачи сертификатов (CA).
• Используя свой секретный асимметричный ключ и тот же самый асимметричный алгоритм шифрования получатель расшифровывает сеансовый ключ.
• Получатель применяет тот же самый симметричный алгоритм шифрования-расшифровки и расшифрованный симметричный (сеансовый) ключ к зашифрованному тексту и получает исходный текст вместе с электронной подписью.
• Получатель отделяет электронную подпись от исходного текста.
• Получатель запрашивает у CA асимметричный открытый ключ отправителя.
• Как только этот ключ получен, получатель расшифровывает его с помощью открытого ключа CA и соответствующего асимметричного алгоритма шифрования-расшифровки.
• Затем расшифровывается хэш-функция текста с использованием открытого ключа отправителя и асимметричного алгоритма шифрования-расшифровки.
• Повторно вычисляется хэш-функция полученного исходного текста.
• Две эти хэш-функции сравниваются для проверки того, что текст не был изменен.

# Transport Layer Security (TLS, SSL)

TLS (англ. transport layer security — Протокол защиты транспортного уровня), как и его предшественник SSL (англ. secure sockets layer — слой защищённых сокетов), — криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети Интернет. TLS и SSL используют асимметричное шифрование для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).

TLS-протокол основан на спецификации протокола SSL версии 3.0, разработанной компанией Netscape Communications.

TLS даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, что нельзя производить прослушивание пакетов и осуществить несанкционированный доступ.

Так как большинство протоколов связи может быть использовано как с, так и без TLS (или SSL), при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Это может быть достигнуто либо с помощью использования унифицированного номера порта, по которому соединение всегда устанавливается с использованием TLS (как, например, порт 443 для HTTPS), либо с использованием произвольного порта и специальной команды серверу со стороны клиента на переключение соединения на TLS с использованием специальных механизмов протокола (как, например, STARTTLS для протоколов электронной почты). Как только клиент и сервер договорились об использовании TLS, им необходимо установить защищённое соединение. Это делается с помощью процедуры подтверждения связи. Во время этого процесса клиент и сервер принимают соглашение относительно различных параметров, необходимых для установки безопасного соединения.

Основные шаги процедуры создания защищённого сеанса связи:

• клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение;
• клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
• сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту;
• сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно цифровой сертификат содержит имя сервера, имя удостоверяющего центра сертификации и открытый ключ сервера;
• клиент, до начала передачи данных, проверяет валидность (аутентичность) полученного серверного сертификата относительно имеющихся у клиента корневых сертификатов удостоверяющих центров (центров сертификации). Клиент также может проверить, не отозван ли серверный сертификат, связавшись с сервисом доверенного удостоверяющего центра;
• для шифрования сессии используется сеансовый ключ. Получение общего секретного сеансового ключа клиентом и сервером проводится по протоколу Диффи-Хеллмана.

Существует исторический метод передачи сгенерированного клиентом секрета на сервер при помощи шифрования асимметричной криптосистемой RSA (используется ключ из сертификата сервера). Данный метод не рекомендован, но иногда продолжает встречаться на практике.

# Алгоритмы, использующиеся в TSL

• Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи), ECDSA;
• Для симметричного шифрования: RC4, IDEA, Triple DES, SEED, Camellia или AES;
• Для хеш-функций: MD5, SHA, SHA-256/384.

# TLS/SSL

Преимущества:

• Невидим для протоколов более высокого уровня;
• Популярность использования в Интернет-соединениях и приложениях электронной коммерции;
• Отсутствие постоянного соединения между сервером и клиентом;
• Позволяет создать туннель для приложений, использующих TCP, таких как электронная почта, инструменты программирования и т. д.

Недостатки:

• Невозможность использования с протоколами UDP и ICMP;
• Необходимость отслеживания состояния соединения;
• Наличие дополнительных требований к программному обеспечению о поддержке TLS.

Аналоги - ssh и ipSec

• IPsec
  • Преимущества:
    • Безопасность и надёжность защиты данных протокола проверена и доказана, так как протокол был принят как Интернет-стандарт;
    • Работа в верхнем слое сетевого протокола и шифрование данных над уровнем сетевого протокола.
  • Недостатки:
    • Сложность реализации, создающая потенциал для уязвимостей;
    • Дополнительные требования к оборудованию сети (маршрутизаторы и т. п.);
    • Существует много различных реализаций, не всегда корректно взаимодействующих друг с другом.
• SSH
  • Преимущества:
    • Позволяет создать туннель для приложений, использующих TCP/IP, таких как электронная почта, инструменты программирования и т. д.;
    • Слой безопасности невидим для пользователя.
  • Недостатки:
    • Трудность использования в сетях с большим числом шлюзов, таких как маршрутизаторы или брандмауэры;
    • Большая нагрузка на внутрисетевой трафик;
    • Невозможность использования с протоколами UDP и ICMP.