Pull to refresh
20
tnvd@tbl

Пользователь

0,4
Rating
Send message
в песочнице сеть не доступна
Можно использовать data: протокол:
«data:application/zip;base64,<base64_encoded_binary>»

Для конвертации в Base64 можете использовать, например, это. Либо скачать/написать утилиту для конвертации.
замена DOS4GW.EXE на DOS32A.EXE
Хм, вы так говорите, будто эволюция — это что-то разумное.
пока писал, подумал, что такая еда уже ведь есть: собачьи и кошачьи сухие корма. Для обеспечения на всю жизнь питомцу нужен только этот корм и вода. Если для человека такое сделать, то и жидкий сойлент не нужен. Только твердый (типа сухариков) и вода.
В этом случае, я бы на месте производителей, выпускал бы в упаковке на один прием пищи твердый сойлент для пережевывания и жидкий — для запивки. Причем, те гранулы твердого, оставшиеся от пережевывания, должны распадаться в течение 10-12 часов по мере прохождения в ЖКТ.
Ну да, банк в первую очередь обезопасивает себя, и только потом — клиента.
Неименная выдаётся практически сразу. У редких банков есть instant issue. Обычно персонализированную карту надо несколько дней ждать. А для целей в статье пойдёт и неименная.
В Dynamic Linq можно повлиять на построение запроса, если не проводить параметризацию, а собирать из строк типа такого:
dataset.Where("allowed == 1 and code == \"" + user_entered_data + "\"");


Атакующий может передать туда
200" or allowed == 0 and code == "200


В результате это все развернется в
select ... from ... where allowed == 1 and code == "200" or allowed == 0 and code == "200"


Еще вариант — какая-нибудь уязвимость в стороннем LINQ-провайдере, позволяющая инжекцию.
А если деплой в руках админов, но кривое приложение порождает шквал вызовов функций подсистемы логирования?
В банке паспорт со всей строгостью проверяют на подлинность?
То, что в СМС пишут, не всегда реально коррелирует с типом транзакции. Ну то есть коррелирует, но шаблон для текста может не отражать всю реальную суть транзакции. Это на усмотрение банка.
В России с ресайклингом точно нет на данный момент. Их использование какие-то ЦБ-шные инструкции нарушает, насколько я слышал.
Диспенсер выдал 10 купюр аккуратной стопочкой, злоумышленник тихонько вытягивает купюру из середины стопки, банкомат ждёт 45 секунд, сжирает назад стопку и отправляет ее в отстойник. Автореверс генерится в ту же минуту. Злоумышленник стал богаче на номинал купюры.
Банки не среагируют до инкассации (пока не сравнят количество оставшихся купюр в кассетах с тем, сколько у них должно быть по учетной системе). Тогда уже поднимаются логи, начинаются разборки: где и кто накосячил.
Есть 2 варианта проверки PIN-а для EMV-чипа: офлайновый и онлайновый. На POS-терминалах до определенной суммы обычно (либо от настроек терминала) проверяют офлайновый пин. На транзакциях с ATM обычно настраивают сразу онлайновую проверку PIN-а.
Кароч, всё зависит от того, что эмитент прошил в данные EMV-карты, настроек POS-терминала/ATM-терминала, настроек эквайера. И все это регулируется хотелками эквайера/эмитента в рамках правил и рекомендаций, навязанных сверху платежной системой.
Матчинг люди настраивают, они могут ошибиться, а ответственные могут не проверить.
Ну вот такой кейс: клиент хочет снять 3000 рублей, банкомат посылает фронту в банке данные, фронт считает (обычно он сам ведет учет купюр в кассете), что в ней купюр достаточно (а на самом деле по какой-то причине там уже пусто) и говорит банкомату: отдай клиенту столько-то купюр из такой-то кассеты. Диспенсер банкомата обнаружил, что бабло клиенту не выдано. Тогда банкомат говорит фронту: Reversal. А фронт-то уже до этого посчитал, что транзакция успешна, даже смс-ку ему послал. Вот он и проводит откат транзакции с попутной отсылкой новой смс-ки.
Вернее 3 вендора: Compass Plus ещё забыл

Information

Rating
2,652-nd
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity