• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Как запретить програмно создавать документы?

R

rtyu

Есть БД db1 в Лотусе. Есть форма form1. В форме 2 поля: field1, field2. Поля должны быть обязательно заполнены, чтобы потом корректно формировались отчеты. Поэтому на событие QuerySave добавлена проверка, что field1 и field2 заполнены. Если не заполнены - ошибка и документ не сохраняется.

Есть пользователь user1 с правами создавать документы в db1. У даного пользователя на локальном компьютере стоит Lotus Notes + Designer. Там же он создал базу db2, которая програмно создает документы в db1. Он делает примерно следующее:


Dim workspace As New Notesuiworkspace
Dim session As New NotesSession
Dim db1 As NotesDatabase
Dim doc As notesdocument

Set db1 = session.Getdatabase("Server", "Path", false)
Set doc = db1.CreateDocument
doc.Form = "form_1"
doc.field_1 = "value_1"

Call workspace.Editdocument(true, doc)
// или возможно
// Call doc.Save( True, True )


После такого кода проверка QuerySave не срабатывает и в db1 пишутся документы с вообще отсутствующим полем field_2. Как можно запретить user1 програмно создавать документы? Или как можно отловить событие перед тем, как документ програмно сохраняется, чтобы провалидировать?
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
ак можно запретить user1 програмно создавать документы?
при сохранении дока в отдельную базу - которую нельзя реплицировать, через серверный агент создаётся док-бюлетень, который подтверждает что док создан правильно

другой агент работающий каждые 5 мин, потом сверяет есть ли на каждый док нужный бюлетень - если нет, удаляет его найфиг ;)

своего рода аналог подписи, но свой
 
R

rtyu

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

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

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Дело в том, что за эти 5 мин много людей могут просмотреть даный даный документ
ну добавь видимость ридерс полями - что новый только создатель видит

Кроме того, это какой-то глобальный вопрос. Получается, что любой пользователь у которого есть права на создание документа может програмно записывать что-угодно, не следуя никаким правилам валидации. Тут же возможность подменять логику. Например, записывать в определенные поля не своего пользователя или роль, а чужие. Это целая дыра в безопасности.
о, чел созрел к ЭЦП
 
R

rtyu

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

Set item = New NotesItem(doc, "$Readers", fieldValues, READERS)

о, чел созрел к ЭЦП
Я не могу принимать решения использования ЭЦП. Очень глобально. Нужны какие-то другие возможности. Кроме того ЭЦП все равно не решит вопрос того, что у меня user1 програмно не заполняет field2
 
Последнее редактирование модератором:

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
олучается, что любой пользователь у которого есть права на создание документа может програмно записывать что-угодно, не следуя никаким правилам валидации
странный вопрос - есть права - значит можно создавать, что удивляет?
валидация - это интерфейсная заморочка
если на сервере - отберите права у юзера, на создание доков, создавайте только серверным агентом
юнид известен - перечитываем док, после сохранения
для возможности заполнять интерактивно - делаем доп. форму для PublicAccess (и права - Write public Documents), форму меняем агентом, в случае удачи
и ваши "хитрецы" обломаются
[doublepost=1499340094,1499339719][/doublepost]разумеется - возможность писать паблик документы у этих юзеров будет (в АКЛ), но эти доки (по такой форме) не будут "приниматься" для отчетов
[doublepost=1499340199][/doublepost]
Кроме того ЭЦП все равно не решит вопрос того, что у меня user1 програмно не заполняет field2
это др. вариант - агент может подписывать админом, и только подписанные админом будут приниматься для отчетов
 
  • Нравится
Реакции: Anatoly

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
ещё как вариант малой кровью - создавать доки в отдельной базе
а оттуды уже серверный агент будет переносить в рабочую - попутно валидируя
в раб. естественно создавать ни у кого прав нет
 
  • Нравится
Реакции: Мыш
R

rtyu

странный вопрос - есть права - значит можно создавать, что удивляет?
валидация - это интерфейсная заморочка
Удивляет, что можно все метаданные подменять, такие как Authors и то, что вся фронтендная валидация и события работают только для фронтенда и не срабатывают, когда события вызываются програмно (например Save вызываем, а QuerySave для формы не срабатывает). Как-то не логично по моему мнению
если на сервере - отберите права у юзера, на создание доков, создавайте только серверным агентом
юнид известен - перечитываем док, после сохранения
для возможности заполнять интерактивно - делаем доп. форму для PublicAccess (и права - Write public Documents), форму меняем агентом, в случае удачи
и ваши "хитрецы" обломаются
ещё как вариант малой кровью - создавать доки в отдельной базе
а оттуды уже серверный агент будет переносить в рабочую - попутно валидируя
в раб. естественно создавать ни у кого прав нет
спасибо, последние 2 варианта рассмотрю. Но думал есть какое-то простое решение. А тут получается, чтобы просто создать ПРАВИЛЬНЫЙ документ, нужны промежуточные формы, агенты...
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
А тут получается, чтобы просто создать ПРАВИЛЬНЫЙ документ, нужны промежуточные формы, агенты...
правильный документ для кого? :)

вот когда этот умный юзер ещё и Scan EZ освоит, вот где вам будет беда ;)
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
спасибо, последние 2 варианта рассмотрю. Но думал есть какое-то простое решение. А тут получается, чтобы просто создать ПРАВИЛЬНЫЙ документ, нужны промежуточные формы, агенты...
вопрос - а где по-другому?
 
R

rtyu

вопрос - а где по-другому?
У меня по другому. Базе уже много лет, писалась не мной. Но про то, что нужно использовать промежуточные формы (или БД) и проверять их агентом, я не знал.
 
Последнее редактирование модератором:

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
У меня по другому. Базе уже много лет, писалась не мной. Но про то, что нужно использовать промежуточные формы (или БД) и проверять их агентом, я не знал.
я про продукты - где можно имея права на создания объекта - "ограничить" его отдельные части
например в РСУБД можно создать триггеры, но это "тот-же" агент ;)
 

Gandliar

Lotus Team
16.02.2004
556
26
BIT
40
После такого кода проверка QuerySave не срабатывает и в db1 пишутся документы с вообще отсутствующим полем field_2. Как можно запретить user1 програмно создавать документы? Или как можно отловить событие перед тем, как документ програмно сохраняется, чтобы провалидировать?


Тут есть два варианта

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

Например из документа 1 я создаю запись справочника (путем создания нового дока2), если я сохраняю новый док2, то скрипт заполняет мне значением поле в документе 1
[doublepost=1499345282,1499344564][/doublepost]если пользователь программист и создает программно доки - наверное можно попробовать сделать агент с триггером after document created or modified который будет обрабатывать документы и проверять, а пользователю дать право создавать только паблик документы которые будет преобразовывать вышеуказанный агент
 
R

rtyu

а) скрипт создал новый док в другой базе и завершился. Таким образом другая база осуществляет контроль за правильностью заполнения полей.
б) Если необходимо проверить правильность заполнения полей в другой базе из текущей базы после завершения скрипта при сохранении нового дока, можно попробовать использовать конструкцию on event querysave ... в этом случае вернется управление в текущую базу.
Чтобы не путаться предлагаю использовать названия баз db1, db2. Как я писал, я управляю db1, к локальной db2 у меня доступа нет. Но там свой локальный админ, который пишет скрипт и там пользователь user1 имеет права на создания документов у меня в db1. Когда он програмно вставляет документ, то событие QuerySave, которое я написал в db1 на форме form1 не срабатывает. И вся моя описаная в QuerySave валидация не работает.
Если я правильно понял, то под предложением
можно попробовать использовать конструкцию on event querysave
имелось ввиду то, что я описал выше. Это событие не вызывается, когда документ создается LotusScript-ом.
 

Gandliar

Lotus Team
16.02.2004
556
26
BIT
40
если пользователь программист и создает программно доки - наверное можно попробовать сделать агент с триггером after document created or modified который будет обрабатывать документы и проверять, а пользователю дать право создавать только паблик документы которые будет преобразовывать вышеуказанный агент
 
R

rtyu

я про продукты - где можно имея права на создания объекта - "ограничить" его отдельные части
например в РСУБД можно создать триггеры, но это "тот-же" агент ;)
С РСУБД сравнивать тяжело, ведь там жестко описана структура. Например, если я в структуре опишу, что у меня field1 - integer not null, то оно никак не позволить мне залить null в field1. А здесь получается, что такое возможно. Здесь по аналогии с РСУБД структура могла бы соответствовать форме. Но нет, структура может быть какая-угодно. Вот и вся прелесть документо-ориентированых СУБД. На основании структуры в РСУБД можно осуществить валидацию, а в Lotus нет.

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

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
С РСУБД сравнивать тяжело, ведь там жестко описана структура. Например, если я в структуре опишу, что у меня field1 - integer not null, то оно никак не позволить мне залить null в field1.
о, теперь ему структура лотуса не нравится :)
 

Gandliar

Lotus Team
16.02.2004
556
26
BIT
40
Ну и сервер у вас видимо есть.
Вот пусть создают в своих базах документы, реплицируют на сервер, а серверный агент валидирует и обрабатывает.
 
R

rtyu

о, теперь ему структура лотуса не нравится :)
К структуре (вернее к её отсутствию) никак претензий нет - документоориентированая фича. А вот к обработке событий вопросы есть. :) Как-то неявно все.
[doublepost=1499347688,1499347155][/doublepost]
Ну и сервер у вас видимо есть.
Вот пусть создают в своих базах документы, реплицируют на сервер, а серверный агент валидирует и обрабатывает.
У меня сервер есть, у них нету. Но я не могу заставить их что-то делать. Моя логика: запретить все, что не разрешено. А разрешить я бы хотел создавать документы только документы, которые проходят валидацию.
Кроме того, все говорят сделать вторую форму form2. А в form1 переносить только провереные документы агентом. Но что я должен показывать всем пользователям после того, как они создают документ? Допустим я создам view2, где отображу все доступные документы из form2. Пользователь создаст документ в form2, агент отработает, валидация не пройдет, данные из документа в form1 скопированы не будут. И тут 2 вариант: 1) либо документ удалится с form2 2) либо он там останется, но не попадет в отчеты, потому что он не валидный.
В любом случае ко мне вопрос: 1) либо почему продают документы 2) либо почему не все документы в отчетах.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
На основании структуры в РСУБД можно осуществить валидацию, а в Lotus нет.
этим занимается движок БД, т.е. кем-то написанный код!
в вашем случае - код не написан (вернее - "написан не там, где надо")
[doublepost=1499347919,1499347704][/doublepost]
Пользователь создаст документ, он сохранится в form2, агент отработает, валидация не пройдет, документ в form1 скопирован не будет
если пользователь сделал программно - расскажите ему правила и дайте возможность смотреть "плохие" документы
тогда и вопросов к вам не будет
можно еще посылать по почте уведомления (*на группу" документов, кот. не прошли валидацию) соответ. юзеру
[doublepost=1499348113][/doublepost]еще вариант - сделайте на xPages, создайте REST API для приложения, там валидируйте данные
хитромордые юзеры сразу будут получать программный отлуп от REST
[doublepost=1499348830][/doublepost]про REST просто, с примерами
там есть ссылки, в т.ч. сюда
 

Вложения

  • bp204final-130201060044-phpapp02.pdf
    1,5 МБ · Просмотры: 958
Последнее редактирование:
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!