Комментарии 39
Гнать из профессии вовсе не нужно. Нужно учиться!
SotrudnikKode
SotrudnikDolgnost
Sotrudnik*
Боже упаси с таким сервисом работать.
А правду говорят, что программисты без знания английского языка попадают в битрикс? ;D
Нет, там же буковки английские. Они отправляются куда-то в направлении РАЯ.
Если ЗнаниеАнгл = 0 Тогда
Предупреждение("Быть тебе 1С-ником всю жЫзнь :)");
КонецЕсли; 
>А правду говорят, что программисты без знания английского языка попадают в битрикс? ;D
Нет, они попадают в 1С
Нет, они попадают в 1С
завис в гугле на поисковом запросе
Следующие операции поддерживаются. Формальное определение см. в Описание службы.
Так и не понял шутка это или нет…
Если нет, то пост уж слишком утрирован. С трудом верится, что такое можно найти у хотя бы более-менее серьезной фирмы в продукции.
Если нет, то пост уж слишком утрирован. С трудом верится, что такое можно найти у хотя бы более-менее серьезной фирмы в продукции.
Можно найти у многих именно когда падает сервер.
Нет, это не шутка. Более того, они о каждом чихе в разработке этой системы гордо отписываются в своём блоге.
Да, кстати, я ещё краем глаза увидел что-то вроде сметы — 7 месяцев разработки в прошлом году (период времени, попавший в эту «смету», вся разработка длится дольше и продолжается до сих пор) обошлась заказчику в >1,5 млн рублей.
Так что кто сомневается — наверно, просто не умеет «впаривать» и набивать цену.
Так что кто сомневается — наверно, просто не умеет «впаривать» и набивать цену.
1) Чтобы что-то быстрее починить в продакшене, лучше, чтоб дебаг был включен. 2) С незакрытыми веб-сервисами проще работать и отлаживать. Плюс «старая добрая» «security through obscurity» — тоже не стоит сбрасывать со счетов.
И вообще, все эти дыры в безопасности напоминают бэкдор, то ли втайне специально оставленный с целью облегчения, ускорения и удешевления последующей поддержки, обслуживания и восстановления работоспособности, то ли не закрытый по недоразумению и забывчивости по схожей причине.
И вообще, все эти дыры в безопасности напоминают бэкдор, то ли втайне специально оставленный с целью облегчения, ускорения и удешевления последующей поддержки, обслуживания и восстановления работоспособности, то ли не закрытый по недоразумению и забывчивости по схожей причине.
Чтобы что-то быстрее починить в продакшене, лучше, чтоб дебаг был включен.
Про дебаг верно, но совсем не обязательно отдавать вывод пользователю.
С незакрытыми веб-сервисами проще работать и отлаживать.
Откройте их для внутренней сети и отлаживайте на здоровье.
Плюс «старая добрая» «security through obscurity» — тоже не стоит сбрасывать со счетов.
Тут это не работает, тысячи ботов постоянно ищут в сети уязвимые сервисы.
Тут, похоже, просто все поленились и/или решили облегчить себе жизнь.
Исполнители делали, наверное, не для себя, а для сторонней организации, и знали, что после окончания работ доступ к сети заказчика перекроют и будут предоставлять только по особому распоряжению, которое надо выпрашивать официальным письмом. Всё это не быстро, а чинить, в случае чего, требуют быстро, могут ещё всякие неустойки требовать за время простоя, и при этом не давать доступ, так что время дорого, и, если первичная диагностика возможна без доступа к внутренней сети, проще не закрывать эту дыру, которая сама по себе не обязательно дыра.
Может быть, там экономят на зарплате «непрофильных работников» типа админов. Может быть, там строгое начальство, которое не любит, когда его грузят проблемами, тем более такими вопросами, в которых оно не может разобраться без посторонней помощи. С таким начальством лучший способ прикрытия своей репутации на работе в случае, когда ты обнаружил проблему, — это попытаться её решить пока больше никто ничего не заметил, а если не получилось, делать всё, чтобы ты с ней не ассоциировался. Если о какой-то «якобы проблеме» сообщает «какой-то там Вася», то, по мнению начальства, это не «проблема существует», а «Вася пытается пиариться и урвать премию», а если проблема «пришла, встала во весь рост и сама начала заниматься вами», то это — да, признанная проблема, но тогда не повезёт всем, кто хоть как-то оказался с ней рядом, и уж точно — тем, кто оказался пресловутым «гонцом, сообщающим плохие вести».
Про торчащие наружу веб-сервисы (кстати, интересно, а сервисы, способные модифицировать данные, тоже были общедоступны?) — ну, типа, «а фиг знает, откуда и когда потребуется вызывать данный сервис, мож с дачи в воскресенье ночью». Может быть, веб-сервисы вообще в другой сетке находятся, тогда нужно думать, для каких IP открывать, остальным давать VPN, а это чревато административными проблемами. В общем, получается, оказалось проще выставить пароли на чтение всему интернету, чем добиться структурных изменений в системе безопасности предприятия.
Если делать совсем грамотно, то доступ к веб-сервисам надо не фильтровать не по принципу «внешняя/внутренняя сеть», а по принципу «авторизован / не авторизован», а это как минимум прикручивание авторизации к SOAP-клиенту, если нет «из коробки», а авторизация — это как минимум поддерживание сессий на стороне сервера (чтоб не гонять постоянно по сети имя с паролем или хэш, который тоже можно перехватить) и решение нетривиального вопроса «как авторизовать клиента когда нет браузера и вообще не предусмотрена лишняя интерактивность». В общем, когда надо быстро, бюджет урезан, а начальство строгое и не любит когда его грузят, зреет понимание, что есть задачи с очевидно большей «добавляемой ценностью» и более легко решаемые.
Насчёт единого пароля для всех учёток — ну тут видится сочетание двух причин: 1) необходимость где-то его хранить, чтоб хотя бы иметь доступ к корпоративной почте сотрудника (через настройку разных админских прав разным начальникам делать трудно, сделаем попроще) 2) непредусмотренности разных паролей для разных служб. Ну ещё возможно, что поменять свой пароль можно только через служебку на имя директора, что потенциально чревато выговором за нарушение правил безопасности.
Ну и до кучи возможен «грамотный юридический контур защиты», когда сообщение в службу безопасности о найденной уязвимости чревато на первой стадии отписками, а на второй, после предъявления информатором доказательств, — судебным преследованием информатора за взлом системы.
Исполнители делали, наверное, не для себя, а для сторонней организации, и знали, что после окончания работ доступ к сети заказчика перекроют и будут предоставлять только по особому распоряжению, которое надо выпрашивать официальным письмом. Всё это не быстро, а чинить, в случае чего, требуют быстро, могут ещё всякие неустойки требовать за время простоя, и при этом не давать доступ, так что время дорого, и, если первичная диагностика возможна без доступа к внутренней сети, проще не закрывать эту дыру, которая сама по себе не обязательно дыра.
Может быть, там экономят на зарплате «непрофильных работников» типа админов. Может быть, там строгое начальство, которое не любит, когда его грузят проблемами, тем более такими вопросами, в которых оно не может разобраться без посторонней помощи. С таким начальством лучший способ прикрытия своей репутации на работе в случае, когда ты обнаружил проблему, — это попытаться её решить пока больше никто ничего не заметил, а если не получилось, делать всё, чтобы ты с ней не ассоциировался. Если о какой-то «якобы проблеме» сообщает «какой-то там Вася», то, по мнению начальства, это не «проблема существует», а «Вася пытается пиариться и урвать премию», а если проблема «пришла, встала во весь рост и сама начала заниматься вами», то это — да, признанная проблема, но тогда не повезёт всем, кто хоть как-то оказался с ней рядом, и уж точно — тем, кто оказался пресловутым «гонцом, сообщающим плохие вести».
Про торчащие наружу веб-сервисы (кстати, интересно, а сервисы, способные модифицировать данные, тоже были общедоступны?) — ну, типа, «а фиг знает, откуда и когда потребуется вызывать данный сервис, мож с дачи в воскресенье ночью». Может быть, веб-сервисы вообще в другой сетке находятся, тогда нужно думать, для каких IP открывать, остальным давать VPN, а это чревато административными проблемами. В общем, получается, оказалось проще выставить пароли на чтение всему интернету, чем добиться структурных изменений в системе безопасности предприятия.
Если делать совсем грамотно, то доступ к веб-сервисам надо не фильтровать не по принципу «внешняя/внутренняя сеть», а по принципу «авторизован / не авторизован», а это как минимум прикручивание авторизации к SOAP-клиенту, если нет «из коробки», а авторизация — это как минимум поддерживание сессий на стороне сервера (чтоб не гонять постоянно по сети имя с паролем или хэш, который тоже можно перехватить) и решение нетривиального вопроса «как авторизовать клиента когда нет браузера и вообще не предусмотрена лишняя интерактивность». В общем, когда надо быстро, бюджет урезан, а начальство строгое и не любит когда его грузят, зреет понимание, что есть задачи с очевидно большей «добавляемой ценностью» и более легко решаемые.
Насчёт единого пароля для всех учёток — ну тут видится сочетание двух причин: 1) необходимость где-то его хранить, чтоб хотя бы иметь доступ к корпоративной почте сотрудника (через настройку разных админских прав разным начальникам делать трудно, сделаем попроще) 2) непредусмотренности разных паролей для разных служб. Ну ещё возможно, что поменять свой пароль можно только через служебку на имя директора, что потенциально чревато выговором за нарушение правил безопасности.
Ну и до кучи возможен «грамотный юридический контур защиты», когда сообщение в службу безопасности о найденной уязвимости чревато на первой стадии отписками, а на второй, после предъявления информатором доказательств, — судебным преследованием информатора за взлом системы.
У вас сплошной негатив, не верю что такое часто встречается у разработчиков ПО, там обычно руководство из программистов и разбирается в теме.
Открывать стенды для всего интернета, к сожалению, приходилось при демонстрации мобильных приложений либо из-за аутсорсеров, которые не могли себе позволить фиксированный IP-адрес и VPN не подходил по какой-то причине.
Открывать стенды для всего интернета, к сожалению, приходилось при демонстрации мобильных приложений либо из-за аутсорсеров, которые не могли себе позволить фиксированный IP-адрес и VPN не подходил по какой-то причине.
Минусующим карму: я не утверждал, что так делать правильно или нужно или вообще можно, я только объяснял мотивы по которым, так делается, несмотря на то, что нельзя.
На днях заказчик (крупный бизнес) тоже попросил дать возможность для одного из подпроектов экспортировать список пользователей с паролями. Бьюсь головой об стену какой день подряд ((
Уже после прочтения названий методов/полей — большего от безопасности и не ждешь)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пять очевидных ошибок, которые почему-то продолжают совершать