среда, 1 мая 2013 г.

День рожденья - грустный праздник

Янтарный луч рассвета застыл в моём окне
Но несмотря на это, немного грустно мне
День наступил и значит всё на своих местах
Но как-то всё иначе, сегодня всё не так

Припев:
День рожденья - праздник детства
И никуда, никуда, никуда от него не деться
День рожденья - грустный праздник
Ты улыбнись, улыбнись, улыбнись, не грусти напрасно
День рожденья - грустный праздник
Ты улыбнись, улыбнись, улыбнись, не грусти напрасно

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

Припев:
День рожденья - праздник детства
И никуда, никуда, никуда от него не деться
День рожденья - грустный праздник
Ты улыбнись, улыбнись, улыбнись, не грусти напрасно
День рожденья - грустный праздник
Ты улыбнись, улыбнись, улыбнись, не грусти напрасно

День рожденья - праздник детства
И никуда, никуда, никуда от него не деться
День рожденья - грустный праздник
Ты улыбнись, улыбнись, улыбнись, не грусти напрасно

вторник, 19 марта 2013 г.

Юмор: Женщина высшего класса

Честно говоря не знаю почему решил опубликовать этот текст.
Видимо где-то очень глубоко он меня зацепил.
А ведь таких историй вагон и маленькая тележка.

#10732 — Женщина высшего класса
Источник http://zadolba.li/

Здравствуй, «женщина среднего класса»! Ты хочешь, чтобы мужчина был зверем в постели, милым с тобой, приносил домой хорошие деньги, красивым и ещё много чего? Изменись сама.

Вот Леночка. Она думает, что выйдя замуж, она навсегда охомутала Игоря. Теперь ей можно не следить за собой, сутками пилить его за маленькую зарплату, самой не работать. Бедный же Игорь впахивает, как проклятый, чтобы купить очередную ненужную хрень для Леночки, но вечером видит ужасное чудовище, готовое его съесть, полный бардак дома и пустые тарелки. Невольно Игорь старается задержаться на работе, пытается отдохнуть с друзьями почаще, просто чтобы не видеть этого безобразия, а Леночка ждёт его дома с перекошенным злым лицом и с новой порцией желчи.

Почему бы Леночке просто не улыбнуться своему мужу после тяжёлого дня и не послушать его? Почему бы не посмотреть на себя в зеркало, не сделать укладку, маникюр и педикюр, не привести личико в порядок? Даже если Леночка не умеет готовить, она ведь может просто прожарить яичницу. Да порадовать мужа в сексуальном плане, наконец! Игорь сам будет рваться домой. У Леночки будут и цветы, и любовь мужа. Крепкий брак, который не разрушит никакая Катенька из соседнего отдела.

Вот Юленька. Она постоянно плачет, что у её Валеры очень маленькая зарплата, и они не вылезают из долгов. Юленька, иди работай! Не хочешь ездить каждый день на работу? Работай дома. Тебе в этом поможет твой любимый интернет, там куча вакансий. Кстати, поумерь свой аппетит касаемо ненужных тебе шмоток — твои шкафы уже лопаются. Ты не поверишь, но Валера будет очень рад, узнав, что ты не сидишь без дела.

Вот Ирочка. У Ирочки есть муж Никита. У них есть общий ребёнок — Лерочка. Ирочка плачет, что она ничего не успевает. А Лерочке, к слову, уже пять лет, она ходит в детский сад. Ирочка не работает. Знаете, чем Ирочка занята? Ирочка собирает урожай в «контакте», у неё там куча подписчиков. Очнись, Ирочка! У тебя целый мир за пределами «контакта», и в этом мире у тебя есть семья! Просто посмотри вокруг. Часа в день тебе хватит, чтобы приготовить поесть и сделать лёгкую уборку дома.

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

Женщины и девушки, мы сами кузнецы своего счастья! А пока вы мне ноете, как вы устали, я сама работаю и радую своего мужа простым супом по вечерам, а он меня на выходных — вкуснейшим завтраком. Пусть я не всегда купаюсь в цветах, зато у меня дома всегда мир и любовь. Пусть я не ношу дорогущие шмотки от ведущих парижских дизайнеров, но ведь не в этом счастье, дорогие мои. Счастье — это когда твой любимый улыбается тебе, как самое тёплое солнышко, когда вы, лёжа на полу в вашей пока что маленькой квартире, пьёте тёплый чай или кофе и думаете, как хотите назвать своих детей (или кота). Счастье — это когда даже самые сложные проблемы вы решаете вместе и помогаете друг другу.

Девушки, вы меня не задолбали. Просто вы какие-то странные.

понедельник, 14 января 2013 г.

MSSQL : Практика предотвращения SQL-injection

Безопасность данных – не место для халтуры

Атака вида SQL-injection продолжает оставаться одной из самых серьезных угроз для SQL Server. База данных может быть восприимчива к таким атакам, если она или приложение (в основном это веб-приложения) содержат код, который хакер может использовать для ввода дополнительной команды SQL в одном из полей ввода приложения. Затем приложение подставляет модифицированный код в базу данных, в результате хакер может получить доступ к конфиденциальной информации, изменению данных или объектов базы данных, и запуску административных операций в базе данных или, в некоторых случаях, по отношению к операционной системе.

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

Введение в SQL-injection

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

Рисунок 1. Ввод идентификатора пользователя в пользовательский интерфейс 

Приложение возвращает список фильмов, которые пользователь взял напрокат. Пользователь вводит идентификатор учетной записи и нажимает Enter. Приложения Приложение или базы данных, объединяет логин с предопределенной командой SELECT так, чтобы логин становится частью условия WHERE. Если пользователь предоставляет правильный логин, список фильмов, возвращается в интерфейсе и все счастливы.

Теперь предположим, что хакер хочет проникнуть в систему для получения данных или нанести ущерб. Например, хакер может попытаться удалить все данные из таблицы аренды (предполагается, что хакер может получить имя таблицы через отдельный хак). Вместо предоставления простого идентификатора пользователя, хакер мог бы также добавить команду TRUNCATE TABLE, как показано на рисунке 2.

Рисунок 2. Ввод изгоев код в пользовательском интерфейсе

Обратите внимание, что значение, введенное в пользовательский интерфейс, теперь включает в себя точку с запятой, а затем команду TRUNCATE TABLE. Поскольку SQL Server поддерживает точку с запятой в качестве разделителя команд и поддерживает несколько команд в блоке, хакер может легко отправить эти команды в базу данных. В результате, таблица аренды будет удалена.

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

Практика предотвращения SQL-injection

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

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

Использование хранимых процедур

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

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

Используйте динамический SQL только тогда, когда вы не можете избежать этого

Динамический SQL может значительно увеличить риск атаки SQL-injection, когда команда языка объединяется с пользовательскими данными. В некоторых случаях, однако, не возможно избежать динамического SQL. Например, вы можете определить хранимую процедуру, которая создает логин в базе данных, где логин передается в качестве параметра. Проблема в том, что заявление CREATE LOGIN не принимает значение переменной для имени, таким образом вы вынуждены построить вашу команду динамически и при этом пройти проверку синтаксиса ядром базы данных.

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

Другим способом предотвращения SQL-injection является использование системной хранимой процедуры sp_executesql, вместо оператора EXECUTE, для выполнения динамических запросов. С помощью хранимой процедуры sp_executesql, у вас есть способ использовать параметризацию динамического запроса, так что с данные остаются отдельно от команд языка. Но убедитесь, что правильно используете хранимую процедуру, не используйте ее в качестве простой замены EXECUTE. Вы должны включить параметры в определение команды при его создании и когда вы вызываете хранимую процедуру sp_executesql.

Используйте принцип наименьших привилегий при предоставлении доступа к базам данных

Даже если вы можете ограничить приложения доступом к хранимым процедурам и избежать использования динамического SQL, вы все равно должны убедиться, что доступ к базе данных ограничивается в полной мере. Одним из ваших лучших средств защиты является следование стратегии наименьших привилегий. Каждой учетной записи базы данных должны быть назначены минимальные права, необходимые для доступа к данным. Именно поэтому ограничение доступа к хранимым процедурам может быть настолько эффективным. В идеале, вы предоставляете право выполнить процедуры и запрещаете доступ к чему-либо еще. Если вы позволяете приложению выполнить SQL запросы напрямую, приложение должно использовать учетные записи с наименьшими привилегиями и, с четким указанием того, что учетная запись может читать и/или изменять в базе данных. Ни при каких обстоятельствах вы не должны назначить учетной записи привилегии администратора (например, sysadmin) в приложении.

Даже внутри хранимых процедур, вы должны следовать стратегии минимального доступа. Например, если вы используете оператор EXECUTE AS, для запуска SQL запросов в процедуре, используйте учетную запись с минимальными привилегиями. Если высокопривилегированная операция должна быть выполнена, создайте хранимые процедуры для выполнения этой операции и подпишите хранимые процедуры с помощью сертификата. Цель состоит в том, чтобы гарантировать, что даже если злоумышленник обнаружит дыру в безопасности приложения, он мало что мог сделать. Приложение, имеющее доступ к БД, всегда должно быть ограничено низким уровнем привилегий учетной записи, имеющей минимальные права для выполнения запросов, выполняемых в базе данных.

Использование тестирования и мониторинга для защиты от SQL-инъекций

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

Защита от атак SQL инъекции

Принципы, предложенные выше, только затрагивают основные темы, но они должны направить вас в правильном направлении. Учитывая распространение мобильных приложений и растущую потребность синхронизировать данные между несколькими устройствами, необходимо проявлять бдительность больше, чем когда-либо. Даже одна уязвимость поставит вашу базу в зону риска, а безопасность данных – не место для халтуры. Разработчики баз данных и разработчики приложений должны работать вместе, чтобы избежать таких уязвимостей. Атаки SQL-injection могут быть предотвращены, но только если вы предпримете необходимые шаги для защиты вашей системы.

ОТДЫХ : Беларусь, Орша

29-го числа мы были в Беларуси, тут нами была намечена первая остановка, в г. Орша.
Я конечно понимаю, что описывая Беларусь, буду не объективен, особенно учитывая тот факт что это первая поездка за границу на автомобиле, но первое впечатление эта страна производит положительное.
Чистые и широкие улицы, ухоженные (по крайней мере покрашенные) дома.
Люди на улицах улыбаются.

Что еще понравилось, так это развитие малоэтажного строительства.
Уже на въезде в город можно увидеть явный новострой, 3-х этажные дома, с 2-мя или 3-мя подъездами.
При этом дома отстоят друг от друга достаточно далеко, что чуствуется пространство между ними.
Тут мне как антипод вспоминается московская и не только московская точечная застройка. Когда башню ставят в вашем дворе, загораживая при этом как вид из окна, так и уничтожая двор.

В общем о Беларусии у меня только положительные впечатления.