Как защитить ресурсы программы

для подсказки — в этой строке есть «THANK YOU» (без кавычек). Сможете ли разобрать строку и понять алгоритм? Насколько он устойчив? Что вообще можете сказать по поводу?

█ 13.10.2014 09:19

По поводу «просто байтов» imho говорить бессмысленно т.к. не не имея алгоритма шифрования никто даже ввязываться не будет в поиск ключа шифрования. Ближе к жизни надо быть. В обычной жизни задача куда более простая по причине того, что дешифровщик доступен в клиентской части приложения. Вот отсюда и плясать надо. Когда есть только байты — говорить даже не о чем.

█ 13.10.2014 09:38

У меня был случай, когда «просто байты», кстати, приблизительно такого же алгоритма, разобрали 🙂 После этого случая я кардинально изменил свое отношение к возможностям дешифровки. И искренне полагаю, что есть очень одаренные в этой области люди, ход мыслей которых я не понимаю в принципе. Потому и спрашивал.

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

Программа защиты ресурсов Windows обнаружила поврежденные файлы

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

█ 13.10.2014 09:57

тут всё зависит от ценности данных. Раз дешифровщик будет доступен в том или ином виде, выкладывай его сюда. 😉 Посмотрим на варианты подбора и попробуем оценить устойчивость.

А если серьёзно, то почему не использовать какой-нибуть rsa или что то подобное. Ключи выдавать лично только тем, кому надо. Если прям очень ценно всё, можно прикрутить хардлок с памятью ключ с него брать. В общем к чему изобретать велосипед?

Источник: olegon.ru

Информационная безопасность web-приложений — современные решения

Веб-приложения — неотъемлемая часть рабочего процесса большинства организаций — АБС системы банков, CRM, 1C и другие программы, которыми ежедневно пользуются сотрудники. Они аккумулируют в себе огромное количество данных, обладающих коммерческой ценностью. Поэтому способствовать обеспечению безопасности веб-приложений — одна из ключевых задач для минимизации финансовых и репутационных рисков бизнеса.

Зачем нужна защита web-приложений?

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

Как защищать личное пространство? / Ната Скрылева // Нам надо поговорить

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

Веб-приложения становятся финансово-привлекательными не только для их разработчиков, но и для желающих нелегально воспользоваться данными, хранящимися в них. Виды и число атак на них растут в геометрической прогрессии. Атаки можно условно поделить на две категории угроз ИБ:

• нарушение конфиденциальности информации;
• нарушение доступности информации.

Наиболее распространенная угроза безопасности web-приложений — это эксплуатация уязвимостей, а при популяризации приложения в интернете — не избежать и DDoS-атак. Для взлома и вывода приложения из строя могут использоваться различные инструменты как любительские, так и профессиональные кибератаки и использование автоматических систем сканирования для эксплуатации уязвимостей.

Первый шаг злоумышленника при попытках атак — сканирование с помощью различных утилит. Это может увидеть администратор по частому обращению с одного IP-адреса к разным страницам и большому числу ошибок 404. Поэтому безопасность веб-приложений начинается с непрерывного мониторинга.

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

Чем грозит утечка конфиденциальной информации из веб-приложения?
Риски делятся на две основные группы:

• финансовые
• репутационные

Например, «горячие» лиды из CRM могут быть перепроданы прямым конкурентам нечестным сотрудником. Утечка клиентской базы, в результате которой клиентские данные оказались в продаже на черном рынке или выложены в публичный доступ, подрывает доверие к организации и влечет ответственность в виде штрафных санкций регуляторов.

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

Как обеспечить безопасность web-приложений?

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

Прямой способ защиты приложений — межсетевой экран или брандмауэр. Для большего числа веб-приложений применяется прикладной сетевой экран Web Application Firewall (WAF). Если же мы говорим о бизнес-приложениях, которые содержат базы коммерческих и персональных данных, — то здесь требуется другой тип защиты — брандмауэр баз данных Database Firewall (DBF). Это позволяет защитить конфиденциальные данные на разных уровнях.

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

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

К основным мерам относятся:

• проверка данных на соответствие стандартам протоколов;
• контроль трафика на основе нейронных сетей;
• сигнатурный анализ;
• защита от SQL-инъекций;
• протекция от межсетевого скриптинга (XSS);
• контроль доступа к конфиденциальным данным.

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

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

Кроме выявления и блокировки атак для защиты данных в приложениях требуется непрерывный мониторинг доступа к базам данных и анализ поведения пользователей и систем. Эти функции обеспечивают решения класса DAM (database activity monitoring). Рассмотрим подробнее принцип работы таких решений.

DAM и DBF — классы систем для защиты веб-приложений

Веб-приложения тесно связаны с СУБД, поэтому атаки, направленные на них могут быть критичными. Получая доступ к приложению, злоумышленник может не только деактивировать его работу, но и завладеть ценной информацией, что грозит крупными финансовыми и репутационными рисками.

Согласно исследованию «Гарда Технологии», базы данных страховых и финансовых компаний оказываются на черном рынке преимущественно из автоматизированных систем, работающих через приложения. Риски утечек могут оцениваться в миллионы долларов. Прибавьте сюда штрафные санкции от регуляторов за нарушение закона о персональных данных и снижение уровня доверия клиентов. Поэтому игнорировать вопрос защиты веб-приложений при веде́нии бизнеса — опрометчивое решение.

Как говорили выше, чтобы защитить бизнес-приложения от современных угроз, одного WAF и сигнатурных средств недостаточно. Требуются специализированные решения для обеспечения безопасности баз данных. Средства по защите баз данных и веб-приложений относятся к классам Database firewall (DBF) / Database Activity Monitoring (DAM) – это аппаратно-программные комплексы для мониторинга, аудита и контроля доступа к информации и защиты от целевых атак на них. Есть решения, объединяющие в себе функциональные возможности по мониторингу, аудиту и защите от атак на базы данных.

В качестве основных функций систем DAM/DBF выделим следующие:

• защита от внешних атак;
• выявление уязвимостей БД;
• обнаружение неучтенных конфиденциальных данных в базах приложений;
• блокировка неавторизованных или нетипичных запросов и ответов;
• проверка данных на обезличенность при передаче;
• тотальный контроль всех запросов к БД и настраиваемые политики безопасности;
• построение профилей пользователей и выявление подозрительной активности;
• автоматическое сканирование БД на наличие конфиденциальной информации;
• расследование инцидентов безопасности;
• предотвращение утечек данных.

Обеспечение информационной безопасности веб-приложений с помощью специализированных систем — это комплексная задача бизнеса и возможность нивелировать риски.

Отечественное решение для информационной безопасности веб-приложений

Первое российское решение для обеспечения безопасности веб-приложений классов DBF и DAM стал аппаратно-программный комплекс «Гарда БД» от производителя систем информационной безопасности «Гарда Технологии».

«Гарда БД» изначально разрабатывалась как система защиты баз данных и веб-приложений. И большинство практических кейсов как раз связано с CRM, 1C, банковскими АБС и другими приложениями, которые используются в ежедневной практике работы сотрудников.

Это система аудита и блокировки сетевого доступа к базам данных и бизнес-приложениям. За счет непрерывного мониторинга обращений к базам данных и веб-приложениям детектирует подозрительные действия в реальном времени.

«Гарда БД» за счет сочетания технологических возможностей обеспечивает комплексную защиту: хранение запросов и ответов для дальнейшего ретроспективного анализа, автоматический поиск неконтролируемых баз данных, поведенческий анализ и выявление нарушений политик ИБ, аналитика и автоматическое уведомление об аномалиях.

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

Поведенческая аналитика позволяет выявлять отклонения от нормального поведения сотрудников или приложений. Все данные собираются в наглядные статистические отчеты, где можно видеть все логины, IP-адреса и запросы к базам данных и приложениям за конкретный период времени, а также большое количество запросов и множественные неуспешные авторизации. Контроль осуществляется по протоколам передачи данных HTTP/HTTPS и протоколам аутентификации.

АПК «Гарда БД» — прогрессивное решение, которое позволяет предотвратить инциденты уже по первым признакам аномального поведения пользователей и систем и обеспечить защиту web-приложений от всех видов угроз. Для тестирования системы в организации предусмотрен бесплатный пилотный проект. Уже за первый месяц работы системы удается предотвратить инциденты информационной безопасности в бизнес-приложениях.

• Информационная Безопасность
• ГБД
• Web-Приложения

Источник: gardatech.ru

Как защитить веб-приложение: основные советы, инструменты, полезные ссылки

Общедоступные веб-приложения интересны хакерам как ресурсы или инструменты заработка. Спектр применения полученной в результате взлома информации широкий: платное предоставление доступа к ресурсу, использование в бот-сетях и т. д. Личность владельца не важна, так как процесс взлома автоматизирован и поставлен на поток. Стоимость информации пропорциональна известности и влиятельности компании.

Если задаться целью, уязвимость в приложении найдётся. В отчёте о хакерских атаках на сайты за 2016 год эксперты Google сообщили о том, что количество взломанных ресурсов увеличилось на 32% по сравнению с 2015 годом, и это не предел. Помните об этом и отбросьте заблуждения о неприступности своих веб-ресурсов, когда планируете работы по информационной безопасности. Специалисты по кибербезопасности востребованы как никогда.

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

Советы по защите веб-приложения от хакеров

Используйте инструменты для анализа защищенности

Это то, что используют в своей работе белые хакеры. Прежде чем искать уязвимости вручную, проверьте приложение автоматизированными средствами. Они выполняют тесты на проникновение, пытаются его взломать, например, при помощи SQL-инъекции.

Заместитель руководителя службы мониторинга и реагирования на инциденты (киберб безопасность) Открытие , , можно удалённо , По итогам собеседования

Ниже приведена подборка бесплатных инструментов.

Приложения и фреймворки

• OpenVAS сканирует узлы сети на наличие уязвимостей и позволяет управлять уязвимостями.
• OWASP Xenotix XSS Exploit Framework сканирует ресурс на возможность эксплуатации XSS-уязвимостей.
• Approof от Positive Technologies проверяет конфигурацию веб-приложения, сканирует на наличие уязвимых компонентов, незащищенных чувствительных данных и вредоносного кода.

Онлайн-сервисы

• SecurityHeaders.io проверяет на наличие и корректность заголовков ответа сервера, отвечающих за безопасность веб-приложения.
• Observatory by Mozilla сканирует ресурс на наличие проблем безопасности. Кроме своих результатов, при выборе соответствующей опции, собирает и добавляет к отчету аналитику со сторонних сервисов анализа защищённости.
• One button scan сканирует на наличие уязвимостей компоненты ресурса: DNS, HTTP-заголовки, SSL, чувствительные данные, используемые сервисы.
• CSP Evaluator проверяет правильность составления политики безопасности содержимого (CSP) и устойчивость к XSS.
• SSL Server Test выполняет анализ SSL-конфигурации веб-сервера.
• ASafaWeb проверяет на наличие распространённых уязвимостей конфигурации сайтов, написанных на ASP.NET.
• Snyk сканирует JavaScript, Ruby и Java-приложения на наличие уязвимостей и, при необходимости, исправляет проблемы безопасности. Интегрируется с GitHub репозиторием для проведения автоматической проверки и оповещает о найденных уязвимостях.

Перед сканированием веб-приложения онлайн-сервисами обратите внимание на условия использования. Некоторые из них публикуют отчеты о проверенных сайтах в открытом виде.

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

После того как в приложение внесены рекомендуемые изменения по безопасности, просканируйте повторно, чтобы убедиться в правильности принятых мер.

Если автоматической проверки мало, попытайтесь вручную взломать свой ресурс, изменяя значения POST и GET запросов. Здесь может помочь отладочный прокси-сервер (например, Fiddler), так как он перехватывает значения HTTP запросов между браузером и сервером. Уделите отдельное внимание формам — попробуйте обойти валидацию, чтобы внедрить XSS-инъекцию.

Если на сайте есть страницы, которые доступны только после аутентификации, попробуйте выдать себя за другого пользователя. Для этого измените параметры URL (например, ID пользователя) или значения Cookie.

Защитите пользовательские данные с помощью HTTPS

HyperText Transfer Protocol Secure (HTTPS) — расширение HTTP, которое поддерживает шифрование и защищает данные пользователей при передаче в Интернете. HTTPS гарантирует целостность и конфиденциальность взаимодействия с сервером. В марте этого года популярность HTTPS достигла переломного момента, и вскоре его использование станет «нормой», а не исключением, как это было раньше.

Используйте HTTPS, если пользователи передают на сервер личные данные: информацию о кредитной карте, персональные данные и даже адреса посещённых страниц. Если при отправке данных с формы авторизации устанавливаются cookie-файлы, которые потом отправляются при каждом запросе к серверу, злоумышленник может получить их и подделать запрос к серверу. В результате он перехватит сессию пользователя. Чтобы предотвратить это, используйте HTTPS на всех страницах сайта.

Это просто: SSL-сертификат генерируется бесплатно (например, на Let’s Encrypt), для большинства платформ созданы инструменты автоматического получения и установки сертификата. Остаётся только включить на сервере поддержку HTTPS.

Примечательно, что компания Google объявила планы о предоставлении сайтам, использующим защищённое соединение, преимущества в результатах поиска. Это пряник. Кнутом станут предупреждения о небезопасном соединении в браузерах, количество которых будет расти. HTTP уходит в прошлое, поэтому самое время перейти на HTTPS.

Если HTTPS уже настроен, хорошей практикой считается использование HTTP Strict Transport Security (HSTS) — заголовка ответа сервера, который запрещает для домена использование незащищённого соединения.

Лучшие практики разработки REST API: 20 советов

Обновляйте программное обеспечение

Это жизненно важно для безопасности веб-приложения. Хакеры регулярно обнаруживают и сразу же применяют новые уязвимости операционных систем и другого программного обеспечения: HTTP-серверов или систем управления контентом (CMS).

Если ресурс расположен на сервере хостинг-провайдера, то установка обновлений для операционной системы входит в комплекс услуг. В противном случае нужно самостоятельно обновлять операционную систему.

Если ресурс работает на базе движка стороннего производителя (CMS или форума), устанавливайте исправления безопасности сразу после выпуска. Большинство разработчиков информируют об обновлениях через рассылку или RSS-канал с описанием исправленных проблем. WordPress и Umbraco, кроме того, уведомляют о доступных обновлениях при входе в панель управления.

Многие разработчики используют менеджеры пакетов (например, Composer, NPM или RubyGems), чтобы устанавливать зависимые компоненты для приложений. В этих пакетах также обнаруживают уязвимости, поэтому следите за их обновлением. Чтобы автоматически получать уведомления о проблемах безопасности пакетов проекта, используйте инструменты вроде Gemnasium.

Предотвратите SQL-инъекции

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

SELECT * FROM table WHERE column = ‘parameter’;

Если злоумышленник изменит значение parameter на ‘ OR ‘1’=’1 , запрос примет следующий вид:

SELECT * FROM table WHERE column = » OR ‘1’=’1′;

Так как ‘1’ равен ‘1’ , атакующий получит доступ ко всем данным таблицы. Это позволит выполнить произвольный запрос, добавив в конец выражения SQL.

Уязвимость этого запроса легко устранить с помощью параметризации. Например, для приложения, написанного с использованием PHP и MySQLi, он выглядит так:

$stmt = $pdo->prepare(‘SELECT * FROM table WHERE column = :value’); $stmt->execute(array(‘value’ => $parameter));

Предотвратите межсайтовый скриптинг

Межсайтовый скриптинг (XSS) — тип атаки на веб-ресурсы, заключающийся во внедрении в страницу сайта вредоносного кода, который выполняется на компьютере пользователя, изменяет страницу и передаёт украденную информацию злоумышленнику.

Например, если на странице комментариев нет проверки входных данных, злоумышленник внедряет вредоносный код JavaScript. В результате у пользователей, которые просматривают комментарий, выполняется код, и данные об авторизации из cookies-файлов отправляются атакующему.

Особенно подвержены этому виду атаки современные веб-приложения, где страницы построены из пользовательского контента, интерпретируемого фронтенд-фреймворками вроде Angular и Ember. В эти фреймворки встроена защита от межсайтового скриптинга, но смешанное формирование контента на стороне сервера и клиента создает новые комплексные атаки: внедрение директив Angular или хелперов Ember.

При проверке сосредоточьтесь на пользовательском контенте, чтобы избежать некорректной интерпретации браузером. Это похоже на защиту от SQL-инъекций. При динамической генерации HTML-кода используйте специальные функции для изменения и получения значений атрибутов (например, element.setAttribute и element.textContent ), а также шаблонизаторы, которые выполняют экранизацию специальных символов автоматически.

Политика безопасности содержимого (CSP) — ещё один инструмент защиты от XSS-атак. CSP — заголовки сервера, определяющие белый список источников, откуда разрешена загрузка данных для разных типов ресурсов. Например, запрет запуска скриптов со стороннего домена или отключение функции eval() . Благодаря политикам CSP даже при внедрении вредоносного кода в страницу его выполнение становится невозможным. На официальном сайте Mozilla размещено руководство по CSP с примерами конфигураций.

Проверяйте и шифруйте пароли

Храните пароли в виде хэша, причём лучше использовать алгоритмы одностороннего хэширования, например, SHA. В этом случае для авторизации пользователей сравниваются хэшированные значения. Если злоумышленник взломает ресурс и получит хэшированные пароли, ущерб будет снижен за счёт того, что хэш имеет необратимое действие и получить из него исходные данные практически невозможно. Но хэши на популярные пароли легко перебираются по словарю, поэтому используйте также «соль», уникальную для каждого пароля. Тогда взлом большого количества паролей становится ещё медленнее и требует больших вычислительных затрат.

Что касается валидации, установите ограничение на минимальную длину пароля, а также делайте проверку на совпадение с логином, e-mail и адресом сайта.

К счастью, большинство CMS предоставляют инструменты управления политиками безопасности, но для использования «соли» или установки минимальной сложности пароля иногда требуется дополнительная настройка или установка модуля. При использовании .NET стоит применить провайдеры членства, потому что в них заложена встроенная система безопасности с большим количеством настроек и готовыми элементами для аутентификации и изменения пароля.

Контролируйте процесс загрузки файлов

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

Даже если установлено ограничение на тип (например, только изображения), относитесь к загружаемым пользователями файлам с подозрением. Расширение или MIME-тип легко подделать, чтение заголовка или использование функций проверки размера изображения не дают 100% гарантии, в большинство форматов изображений возможно внедрить код PHP, который будет выполнен на сервере.

Чтобы это предотвратить, запретите исполнение загружаемых файлов пользователями. По умолчанию веб-серверы не пытаются выполнить файлы с расширениями изображений, но не стоит полагаться только на расширение. Известны случаи, когда файл image.jpg.php обходил эту проверку.

Способы ограничения доступа:

• переименовывать или изменять расширения файлов при загрузке;
• изменять разрешения, например, на chmod 0666 ;
• создать файл .htaccess (см. пример ниже), который откроет доступ только к указанным типам файлов.

deny from all order deny,allow allow from all

Более безопасный способ –— запретить прямой доступ к загружаемым файлам, разместив их, например, вне папки корня сайта. Однако в этом случае потребуется создать скрипт (или обработчик HTTP в .NET), чтобы извлекать файлы из закрытой части и выдавать пользователю.

Меры защиты веб-приложений для владельцев собственных серверов:

1. Настройте межсетевой экран, в том числе на блокировку неиспользуемых портов.
2. При наличии доступа к серверу из локальной сети создайте демилитаризованную зону (DMZ), открыв доступ из внешнего мира только к портам 80 и 443.
3. При отсутствии доступа к серверу из локальной сети используйте защищённые методы (SFTP, SSH и др.) для передачи файлов и управления сервером извне.
4. Если возможно, выделите отдельный сервер для баз данных, который не будет напрямую доступен из внешнего мира.
5. Отграничьте физический доступ к серверу.

Следите за сообщениями об ошибках

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

Чтобы держать руку на пульсе проекта, установите систему мониторинга ошибок. Например, Sentry, которая автоматически получает ошибки от обработчиков в коде приложения и через форму от пользователей, а также предоставляет панель для управления ими в реальном времени.

Проверяйте входящие данные

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

Распределяйте права доступа к файлам

Разрешения файла (file permissions) определяют КТО и ЧТО может с ним делать.

В *nix системах у файлов 3 варианта доступа, которые представляются в виде цифр:

• «Read» (4) — чтение содержимого файла;
• «Write» (2) — изменение содержимого файла;
• «Execute» (1) — выполнение программы или скрипта.

Чтобы установить множественные разрешения, достаточно сложить их числовые значения:

• «Чтение» (4) + «запись» (2) = 6;
• «Чтение» (4) + «запись» (2) + «выполнение» (1) = 7.

При распределении прав пользователи делятся на 3 типа:

• «Owner» (владелец) — создатель файла (изменяем, но может быть только один);
• «Group» (группа) — группа пользователей, которые получают разрешения;
• «Others» (прочие) — остальные пользователи.

Установка владельцу прав доступа на чтение и запись, группе — на чтение, прочим — запрет доступа выглядит так:

Чтение

Запись

Выполнение

Владелец

Источник: tproger.ru