Сериализация XML туда и обратно DateTime и xsd:date?
В порядке, достаточно остановки; вот то, что я придумал до сих пор
(извините, длинное сообщение вперед. Будьте храбры, друг, поездка будет стоить того)
методы Объединения 3 и 4 из исходного сообщения в своего рода 'нечеткий' или динамический белый список, и затем - и вот прием - не, блокирование не добавило дюйм/с в белый список, просто регулируя их к черту и назад .
Примечание, что эта мера только означали мешать этому очень определенному типу нападения. На практике, конечно, это работало бы в сочетании с другими подходами лучших практик к автору: регулировка фиксированного имени пользователя, регулировка на IP, осуществленная кодом политика сильного пароля, неотрегулированный вход в систему cookie, хеширование всех эквивалентов пароля прежде, чем сохранить их, никогда не используя вопросы о безопасности, и т.д.
Предположения о сценарии
нападения, Если взломщик нацелен на переменные имена пользователей, наша регулировка имени пользователя, не стреляют. Если взломщик использует ботнет или имеет доступ к большому диапазону IP, наша регулировка IP бессильна. Если взломщик предварительно очистил наш userlist (обычно возможный на веб-сервисах открытой регистрации), мы не можем обнаружить продолжающееся нападение на основе числа 'пользователя, не найденного' ошибки. И если мы осуществим строгое в масштабе всей системы (все имена пользователей, весь дюйм/с) регулировка, то любое такое нападение будет DoS наш весь сайт на время нападения плюс период регулировки.
, Таким образом, мы должны сделать что-то еще.
первая часть контрмеры: Белый список
, В чем мы можем быть абсолютно уверены, то, что взломщик не может обнаружить и динамично имитировать IP-адреса нескольких тысяч наших пользователей (+). Который делает белый список выполнимый. Другими словами: для каждого пользователя мы храним список (хешированного) дюйм/с от того, где пользователь ранее (недавно) вошел в систему.
Таким образом, наша схема белого списка будет функционировать как заблокированную 'парадную дверь', где пользователь должен быть соединен от одного из его распознанного 'хорошего' дюйм/с для входа в систему вообще. Атака перебором этой 'парадной двери' была бы практически невозможна (+).
(+), если взломщик не 'владеет' или сервером, полями всех наших пользователей или самим соединением - и в тех случаях, у нас больше нет проблемы 'аутентификации', у нас есть подлинный размера франшизы, отключают ситуация FUBAR
вторая часть контрмеры: в масштабе всей системы регулируя из нераспознанного дюйм/с
, Чтобы заставить белый список работать на веб-сервис открытой регистрации, где пользователи часто переключают компьютеры и/или подключение от динамических IP-адресов, мы должны сохранить 'дверь для кошки' открытой для пользователей, соединяющихся от нераспознанного дюйм/с. Прием должен разработать ту дверь, таким образом, ботнеты застревают, и таким образом, законные пользователи становятся побеспокоенными как можно меньше .
В моей схеме, это достигается установкой a очень строгое максимальное количество неудавшихся попыток входа в систему неутвержденного дюйм/с, скажем, 3-часовой период (может быть более мудро использовать более короткий или более длительный период в зависимости от типа сервиса), и создание, что ограничение , глобальное , т.е. для всех учетных записей пользователей.
Даже медленное (1-2 минуты между попытками) грубую силу обнаружили бы и мешали бы быстро и эффективно использующий этот метод. Конечно, действительно медленный грубая сила могла все еще остаться незамеченным поражением, но слишком низких скоростей самая цель атаки перебором.
то, Что я надеюсь выполнить с этим механизмом регулировки, то, что, если максимальный предел достигнут, наши хлопки 'двери для кошки', закрытые некоторое время, но наша парадная дверь остается открытой для законных пользователей, соединяющихся обычными средствами:
- Или путем соединения от одного из их распознанного дюйм/с
- Или при помощи персистентного cookie входа в систему (отовсюду)
единственные законные пользователи, которые были бы затронуты во время нападения - т.е. в то время как регулировка была активирована - будут пользователями без персистентных cookie входа в систему, которые входили в систему от неизвестного местоположения или с динамическим IP. Те пользователи не могли бы войти в систему, пока регулировка не смягчилась (который мог потенциально требовать времени, если бы взломщик поддерживал свой ботнет в рабочем состоянии несмотря на регулировку).
, Чтобы позволить этому небольшому подмножеству пользователей протискиваться через иначе изолированную дверь для кошки, даже в то время как боты все еще усердно работали над ним, я буду использовать 'резервную' форму входа в систему с КАПЧОЙ. Так, чтобы, когда Вы отображаетесь "Извините, но Вы не можете войти от этого IP-адреса в данный момент" в сообщение, включать ссылку, в которой говорится" безопасный резервный вход в систему - ЛЮДИ ТОЛЬКО ( боты: никакая ложь ) ". Шутите в стороне, когда они нажимают на ту ссылку, дают им reCAPTCHA-аутентифицируемую форму входа в систему, которая обходит по всему сайту регулировку. Тот путь, ЕСЛИ они люди И знают корректный login+password (и может считать КАПЧИ), они будут никогда быть отклоненными в сервисе, даже если они будут соединяться от неизвестного хоста и не использовать cookie автовхода в систему.
, О, и просто для уточнения: Так как я действительно полагаю, что КАПЧИ являются обычно злыми, 'резервная' опция входа в систему была бы только [1 146] появляться , в то время как регулировка была активна .
нет никакого отклонения, что длительное нападение как этот все еще составило бы форму DoS-атаки, но с описанной системой на месте, это будет только влиять на то, что я подозреваю, чтобы быть крошечным подмножеством пользователей, а именно, люди, которые не используют, "помнят меня" cookie И, оказывается, входят в систему, в то время как нападение происходит И не входит в систему ни от одного их обычного дюйм/с И кто не может считать КАПЧИ. Только те, кто может сказать "нет" ВСЕМ тем критериям - конкретно ботам и действительно неудачный инвалиды - будут отклонены во время нападения бота.
РЕДАКТИРОВАНИЕ: Actully, я думал о способе позволить даже БРОШЕННЫМ ВЫЗОВ КАПЧОЙ пользователям пройти во время 'блокировки': вместо, или как дополнение к, резервный вход в систему КАПЧИ, предоставляют пользователю опцию иметь единственное использование, определенный для пользователя код блокировки, отправленный в его электронную почту, которую он может затем использовать для обхода регулировки. Это определенно пересекает мой порог 'раздражения', но так как он используется только в качестве последнее средство для крошечного подмножества пользователей, и так как он все еще бьет быть заблокированным из Вашей учетной записи, это было бы приемлемо.
(Кроме того, обратите внимание, что ни одного из этого не происходит, если нападение так менее сложно, чем противная распределенная версия, я описал здесь. Если нападение произойдет от только некоторых дюйм/с или только поразит несколько имен пользователей, то этому будут мешать намного ранее, и с [1 150] никакой по всему сайту последствия)
<час>Так, который является контрмерой, которую я буду реализовывать в своей подлинной библиотеке, после того как я убежден, что это звуковое и что нет большого простого решения, которое я пропустил. Факт, существует столько тонких способов сделать вещи неправильно в безопасности, и я не выше создания ложных предположений или безнадежно испорченной логики. Таким образом, любой и вся обратная связь, критика и улучшения, тонкость и т.д. высоко ценятся.
2 ответа
Я открыл проблему с подключением и получил ответ от Microsoft, подтверждающий мои опасения:
У нас разное поведение для обработка даты, времени и DateTime ценности. Для значений DateTime, если XmlDateTimeSerializationMode не Местная информация о виде (UTC, местное или неопределенное) сохранились. Это также верно, пока десериализация. Однако для Date и Время, они всегда сериализуются в том же формате: (гггг-ММ-дд для Дата и ЧЧ: мм: ss.fffffff.zzzzzz для Время). Итак, информация о виде теряется при сериализации и десериализация. Мы открываем ошибка документации на нашей стороне в порядке улучшить документацию о это.
Я не вижу проблемы, которую вы описали.
Ваш пример кода не десериализуется. Я добавил код для десериализации, и он работает, как я и ожидал. Я не видел, чтобы дата переместилась на день назад или на день вперед.
Я заметил , что временная часть поля d.Date удаляется для сериализации, независимо от DateTimeKind. Мне это кажется правильным. Для меня интуитивно не имеет смысла либо сериализовать часовой пояс с «Датой», либо преобразовывать в UTC. Для меня было бы удивительно, что если бы у меня было значение Date 8-18-2009, а при сериализации оно появилось бы как 8-19-2009Z. Поэтому я думаю, что то, как это работает сейчас, кажется правильным.
- DateTime, сериализованный как xsd: dateTime, включает информацию о зоне.
- DateTimes сериализован как xsd: date, нет. Я также ожидал, что с
[XmlElement (DateType = "time")](xsd: time) часовой пояс не будет включен. Я не' t проверить это.
Итак, проблема, как я вижу, заключается в том, что это поведение, которое имеет для меня смысл, четко не задокументировано, особенно с изменениями, внесенными для двусторонней передачи. Следует четко указать тот факт, что DataType = "date" и DataType = "time" не преобразуются в UTC для сериализации.
вы написали:
и любое преобразование в UTC изменит как минимум время суток,
Но я этого совсем не видел. Когда я конвертирую время DateTimeKind.Unspecified в Utc, оно не меняет время дня. Это просто меняет вид.
class Program
{
static System.IO.MemoryStream StringToMemoryStream(string s)
{
byte[] a = System.Text.Encoding.ASCII.GetBytes(s);
return new System.IO.MemoryStream(a);
}
static void Main(string[] args)
{
var settings = new System.Xml.XmlWriterSettings { OmitXmlDeclaration = true, Indent= true };
XmlSerializerNamespaces _ns = new XmlSerializerNamespaces();
_ns.Add( "", "" );
Console.WriteLine("\nDate Serialization testing...");
for (int m=0; m < 2; m++)
{
var builder = new System.Text.StringBuilder();
DateTime t = DateTime.Parse("2009-08-18T22:31:24.0019-04:00");
DateSerTest d = new DateSerTest
{
Date = t,
DateTime = t
};
Console.WriteLine("\nRound {0}", m+1);
if (m==1)
d.Date = d.Date.ToUniversalTime();
Console.WriteLine("d.Date {2,-11} = {0} Kind({1})", d.Date.ToString("u"), d.Date.Kind.ToString(),
(m==1) ? "(converted)" : "(original)" );
Console.WriteLine("d.DateTime = {0} Kind({1})", d.DateTime.ToString("u"), d.DateTime.Kind.ToString());
XmlSerializer ser = new XmlSerializer(typeof(DateSerTest));
Console.WriteLine("\nSerialize d");
using ( var writer = System.Xml.XmlWriter.Create(builder, settings))
{
ser.Serialize(writer, d, _ns);
}
string xml = builder.ToString();
Console.WriteLine("{0}", xml);
Console.WriteLine("\nDeserialize into d2");
System.IO.MemoryStream ms = StringToMemoryStream(xml);
DateSerTest d2= (DateSerTest) ser.Deserialize(ms);
Console.WriteLine("d2.Date = {0} Kind({1})", d2.Date.ToString("u"), d2.Date.Kind.ToString());
Console.WriteLine("d2.DateTime= {0} Kind({1})", d2.DateTime.ToString("u"), d2.DateTime.Kind.ToString());
Console.WriteLine("\nAfter SpecifyKind");
d2.Date = DateTime.SpecifyKind(d2.Date, DateTimeKind.Utc);
Console.WriteLine("d2.Date = {0} Kind({1})", d2.Date.ToString("u"), d2.Date.Kind.ToString());
Console.WriteLine("\nRe-Serialize d2");
builder = new System.Text.StringBuilder();
using ( var writer = System.Xml.XmlWriter.Create(builder, settings))
{
ser.Serialize(writer, d2, _ns);
}
xml = builder.ToString();
Console.WriteLine("{0}", xml);
}
}
}
Результаты:
Date Serialization testing...
Round 1
d.Date (original) = 2009-08-18 22:31:24Z Kind(Local)
d.DateTime = 2009-08-18 22:31:24Z Kind(Local)
Serialize d
<DateSerTest>
<Date>2009-08-18</Date>
<DateTime>2009-08-18T22:31:24.0019-04:00</DateTime>
</DateSerTest>
Deserialize into d2
d2.Date = 2009-08-18 00:00:00Z Kind(Unspecified)
d2.DateTime= 2009-08-18 22:31:24Z Kind(Local)
After SpecifyKind
d2.Date = 2009-08-18 00:00:00Z Kind(Utc)
Re-Serialize d2
<DateSerTest>
<Date>2009-08-18</Date>
<DateTime>2009-08-18T22:31:24.0019-04:00</DateTime>
</DateSerTest>
Round 2
d.Date (converted) = 2009-08-19 02:31:24Z Kind(Utc)
d.DateTime = 2009-08-18 22:31:24Z Kind(Local)
Serialize d
<DateSerTest>
<Date>2009-08-19</Date>
<DateTime>2009-08-18T22:31:24.0019-04:00</DateTime>
</DateSerTest>
Deserialize into d2
d2.Date = 2009-08-19 00:00:00Z Kind(Unspecified)
d2.DateTime= 2009-08-18 22:31:24Z Kind(Local)
After SpecifyKind
d2.Date = 2009-08-19 00:00:00Z Kind(Utc)
Re-Serialize d2
<DateSerTest>
<Date>2009-08-19</Date>
<DateTime>2009-08-18T22:31:24.0019-04:00</DateTime>
</DateSerTest>