Если верить открытым источникам, рынок электросамокатов в России главным образом держат Whoosh и Urent (хотя сейчас ещё Яндекс вклинивается, и с его ресурсами это вполне возможно). При этом у Urent больше городов и больше самокатов, чем у Whoosh, но ниже доходы.
Я подумал: наверняка бизнес-аналитики Urent днями и ночами сидят и ломают голову, что бы им поменять и улучшить, чтобы начать выигрывать эту конкуренцию. Строят теории, проводят тесты. Сложная работа, в общем, бизнес и рынок не такие предсказуемые вещи.
А потом я воспользовался Urent и за 5 минут нашел столько косяков UI/UX в приложении, что мне стало всё понятно. Кроме того, почему Urent ничего с этими косяками не делает.
1. Сканирование кода в Whoosh приводит к появлению полноэкранной модалки с большими кнопками и основной информацией о самокате и стоимости. Сканирование кода в Urent выдает в самом низу экрана блок кнопок, в которые не только очень сложно попасть, но его ещё и надо скроллить (см. левый скриншот). При этом весь экран занят уже не нужной к этому моменту камерой. Такой интерфейс заточен под перебор самокатов, но на деле человеку на улице на ходу нужно просто максимально быстро взять первый самокат, к которому он подошёл.
2. О том, что страховка включена и будет стоить дополнительных денег, можно догадаться только за счёт знания об этой функции из других сервисов. Да, Whoosh, конечно, поступает очень по-мудачески, постоянно автоматически включая платную страховку, из-за чего её надо выключать вручную каждый раз при каждом заказе. Но в Urent необходимость этого действия ещё и довольно неочевидна (а страховка тоже, конечно же, по-умолчанию всегда включена).
3. Я отсканировал самокат, затем нажал подтверждение заказа. Система после этого написала мне, что данный самокат недоступен. Неужели, нельзя об этом писать ещё на этапе сканирования? Зачем выводить кнопку заказа для недоступного самоката?
4. Кнопка перехода к текущей геопозиции перекрыта неубирающейся шторкой снизу (см. правый скриншот).
И это только вещи, которые прям за первые 5 минут выявляются и очень на поверхности. А исправить их может один программист и один дизайнер за пару недель. Удивительно, как некоторые бизнесы не хотят зарабатывать.
#dev
👨💻 Attacking Policy.
• Open Policy Agent — это open-source-инструмент контроля доступа, основанный на политиках, который создан в 2016 году и с тех пор стабильно развивается. Сейчас он входит в каталог дипломированных проектов Cloud Native Computing Foundation (CNCF). Его используют Netflix, Pinterest, TripAdvisor и другие компании.
• В этой статье перечислены определенные векторы атак, которые могут быть вызваны неправильной конфигурацией Open Policy Agent:
• Allowed Repositories;
• Automount Service Account Token for Pod;
• Block Endpoint Edit Default Role;
• Block Services with type LoadBalancer;
• Block NodePort;
• Block Wildcard Ingress;
• Disallow Interactive TTY Containers;
• Step-by-Step Instructions;
• Allow Privilege Escalation in Container;
• Step-by-Step Instructions;
• Privileged Container;
• Read Only Root Filesystem;
• Host Networking Ports;
• App Armor;
• SELinux V2;
• Resources.
#devsecops
👩💻 Attacking NodeJS Application.
- Use flat Promise chains;
- Set request size limits;
- Do not block the event loop;
- Perform input validation;
- Perform output escaping;
- Perform application activity logging;
- Monitor the event loop;
- Take precautions against brute-forcing;
- Use Anti-CSRF tokens;
- Prevent HTTP Parameter Pollution;
- Do not use dangerous functions;
- Use appropriate security headers;
- Listen to errors when using EventEmitter;
- Set cookie flags appropriately;
- Avoid eval(), setTimeout(), and setInterval();
- Avoid new Function();
- Avoid code serialization in JavaScript;
- Use a Node.js security linter;
- References.
#devsecops
👨💻 Attacking APIs \ Атаки на API.
• Программный интерфейс приложений (API) - фундаментальный элемент инноваций в современном, движимом приложениями мире. API - важная составляющая современных мобильных, SaaS и веб приложений, используемая в клиентских, партнерских и внутренних приложениях от банковской сферы, сфер розничных продаж и логистики до интернета вещей, автономных автомобилей и умных городов.
• По своей природе API раскрывают логику приложения и критичные данные, например, персональные данные, именно поэтому API все чаще становятся целью злоумышленников. Стремительные инновации невозможны без безопасных API. В этой статье рассматриваются общие векторы атак на API и приводятся примеры безопасной разработки.
➡️https://blog.devsecopsguides.com/attacking-apis
#devsecops
👨💻 Attacking Pipeline.
• DevOps resources compromise;
• Control of common registry;
• Direct PPE (d-PPE);
• Indirect PPE (i-PPE);
• Public PPE;
• Changes in repository;
• Inject in Artifacts;
• User/Services credentials;
• Typosquatting docker registry image;
• Resources.
#DevOps#DevSecOps