Проблемы разработки, безопасности и жизни
Cтикеры – https://t.me/addstickers/hackerwomanParadisecurity
Есть вопросы, пиши @mother_paradisecurity_bot
Post #79
2.36K
Channel Public Channel
PA paradiSEcurity
@paradisecurity
- Subscribers
- 1.96K
- Photos
- 72
- Videos
- 6
- Links
- 143
Showing posts older than #80 · Back to latest
Older Posts 20 shown
Post #78
2.39K
Отличная книга, которую я упустила. Она устарела уже ввиду того что была выпущена в 2015, но, в целом, многие аспекты до сих пор актуальны. Хоть андроид и быстро меняется, по факту радикальных изменений ядра не происходило. Очень советую ознакомиться. Автор серьезный человек, который вместе с командой ведет семинары для спецслужб, ну и просто заинтересованных лиц (за денежку, конечно же). У меня +к планам появилось желание попасть на это мероприятие:)
Если появится желание задонатить автору, можно купить физическую книжку. Автор сам распространяет книгу в открытом доступе, тк она была слита.
Если появится желание задонатить автору, можно купить физическую книжку. Автор сам распространяет книгу в открытом доступе, тк она была слита.
Post #77
2.37K
Сегодня отличный вечер. И я бы хотела поговорить с вами об одной очень важной вещи. Изначально я создала этот канал для популяризации информационной безопасности в мобильном мире. Я люблю свою работу и вообще, чем занимаюсь, и меня очень радует, что в такой узкой специализации я нашла уже более трехсот единомышленников.
Вы, наверно, заметили, что я периодически рекомендую доклады и статьи других людей, которые так или иначе тоже интересуется тем же, чем и я, мы общаемся и пытаемся заинтересовать и других людей тем, чем занимаемся.
Я знаю, что писать полноценные тексты сложно, и я знаю, что есть очень много людей, которые бы хотели сделать свой вклад, но зачастую просто не знают о чем писать. И зачем писать?
Действительно, зачем...
По стилю нашей профессии мы должны писать код, а не изворачиваться в деепричастных оборотах. Но написание статей помогает мне упорядочить свои знания и сделать их более устойчивыми, лучше разобраться в теме, закрыть пробелы, уложить материал в голове так, чтобы он остался там надолго и, надеюсь, помочь кому-то, сэкономить время, сделать свои выводы и, возможно, прийти к более лучшему решению.
Потому, если вы столкнулись с какой-то проблемой, не обязательно касающуюся иб или мобильной разработки, и когда решили ее (или даже если не решили), вы подумали: а это ведь интересно, я хотел бы обсудить это с кем-нибудь. То пишите тексты, публикуйте их где угодно. Поднимайте общую осведомленность и делайте разработку профессиональнее. Потому что если с вашей проблемой столкнется другой человек, не факт что он добьется в ее решении такого же успела как и вы, или такого успеха, какого мог бы добиться, если бы он знал о вашем решении и его последствиях.
Вы, наверно, заметили, что я периодически рекомендую доклады и статьи других людей, которые так или иначе тоже интересуется тем же, чем и я, мы общаемся и пытаемся заинтересовать и других людей тем, чем занимаемся.
Я знаю, что писать полноценные тексты сложно, и я знаю, что есть очень много людей, которые бы хотели сделать свой вклад, но зачастую просто не знают о чем писать. И зачем писать?
Действительно, зачем...
По стилю нашей профессии мы должны писать код, а не изворачиваться в деепричастных оборотах. Но написание статей помогает мне упорядочить свои знания и сделать их более устойчивыми, лучше разобраться в теме, закрыть пробелы, уложить материал в голове так, чтобы он остался там надолго и, надеюсь, помочь кому-то, сэкономить время, сделать свои выводы и, возможно, прийти к более лучшему решению.
Потому, если вы столкнулись с какой-то проблемой, не обязательно касающуюся иб или мобильной разработки, и когда решили ее (или даже если не решили), вы подумали: а это ведь интересно, я хотел бы обсудить это с кем-нибудь. То пишите тексты, публикуйте их где угодно. Поднимайте общую осведомленность и делайте разработку профессиональнее. Потому что если с вашей проблемой столкнется другой человек, не факт что он добьется в ее решении такого же успела как и вы, или такого успеха, какого мог бы добиться, если бы он знал о вашем решении и его последствиях.
Post #76
2.19K
#shkryaba
Немного информации об ANR. Надеюсь, вам не придется решать такие проблемы, но всякое бывает ;)
Немного информации об ANR. Надеюсь, вам не придется решать такие проблемы, но всякое бывает ;)
Post #75
2.26K
Post #72
2.54K
Запускаю новую рубрику — Подборка хороших материалов
Как работает Android
Android: новый метод рутинга и большое исследование безопасности IPC в приложениях
Разработка библиотеки: от API до публичного релиза
Как научить людей использовать Git
D8/R8 vs DX/Proguard - видео
Акция не регулярная, но периодически, когда у меня самой застой, я буду организовывать что-нибудь подобное:)
P.S. Приходите на MOSDROID - https://habr.com/ru/post/437368/
Как работает Android
Android: новый метод рутинга и большое исследование безопасности IPC в приложениях
Разработка библиотеки: от API до публичного релиза
Как научить людей использовать Git
D8/R8 vs DX/Proguard - видео
Акция не регулярная, но периодически, когда у меня самой застой, я буду организовывать что-нибудь подобное:)
P.S. Приходите на MOSDROID - https://habr.com/ru/post/437368/
Post #71
2.24K
Я очень часто замечаю, что программисты не умеют управлять своими финансами, в плане того же вложения денег в какие-то подручные инструменты или вообще в отношении общих трат. Иногда они не покупают шампунь, потому что он дороже на 30 рублей и в тот же момент с огнем в глазах отдают свои кровно заработанные 80$ за Sublime Text, который имеет уйму бесплатных аналогов. Они даже не задумываются о том, сколько стоит их время и сколько стоят они сами. А темы касательно зарплат и финансов хоть всех и интересуют, но прямые разговоры об этом чуть ли не порицаются. И эта финансовая неграмотность ведёт к тому, что вроде программисты и зарабатывают хорошо, но в итоге деньги куда-то уходят, на что - непонятно, а видимого результата нет.
Post #70
2.31K
Раз уж пошла такая пляска, то вот вам свежая статья о том, как прятать свои данные в Android-приложении. Советую ознакомиться;)
Post #69
2.05K
Сейчас очень распространено мнение, что если тебе нечего скрывать, то тебе вроде как должно быть все равно, имеет кто-то доступ к твоим личным данным или нет. Я думаю, что это в корне неправильно, а вы?
Post #68
2.25K
Post #66
2.59K
И да, я еще жива, несмотря на бурные праздники 🙈
- ❤ 1
Post #65
2.41K
Должен ли разработчик пользоваться тем, что разрабатывает?
Программное обеспечение представляет из себя десятки миллионов строчек кода, а количество разработчиков, стоящих за ними, достигает миллиона. Каждый программист, который занимается разработкой какого-либо продукта — это человек, у которого есть свои желания и стремления. Он так же покупает технику, как и его сосед юрист/врач/менеджер, водит машину, ходит в кино.
Когда я еще училась в универе, мой друг рассказал мне, как он сходил на конференцию, где был один из разработчиков платформы Windows Phone (мой друг как раз тогда занимался разработкой именно под WP). И когда он, воодушевленный, решил подойти к этому разработчику и задать ему пару вопросов, тот предложил сфотографироваться всем вместе и достал для этого новенький iPhone. Запал моего друга поутих. Так вот, значит ли это хоть что-нибудь?
Сейчас, когда мы уже на несколько лет впереди от этой ситуации, мы легко можем сказать, что этот разработчик просто сам не верил в собственный продукт, а если разработчик не верит в то, что разрабатывает — неудивительно, что это в итоге разваливается.
На мой взгляд, это немного не так. Однако и часть правды в этом так же есть.
Сложно сказать разработчику какой-нибудь космической программы попробовать ее использовать 24/7. Тут я скорее говорю о таких проектах, которыми мы в итоге действительно пользуемся, но по какой-то причине выбираем другой аналог, а не тот продукт, который или для которого мы что-то создаем.
Если вы разрабатываете приложение для автомобиля (карты, сбор статистики, такси), то вы должны уметь водить, потому что это позволит вам сформировать представление о том, как это все должно работать и насколько удобно пользоваться создаваемым вами продуктом другим людям в реальной жизни. Пишите какую-то операционную систему — пользуйтесь ей. Пишите приложения под iOS, используйте iPhone, пишете под Android — используйте Android.
Вы можете сказать, что все это неважно, ведь разработчик зачастую видит только строки кода и задачи в канбане. Какая ему разница, как работает то, что он создает, это задача уже архитектора и проектного менеджера, который пихает задачи и вообще кого угодно, но не его... Задача разработчика — писать код и чтобы его код не падал. И да, это тоже сработает, однако, к сожалению, если вы не имеете достаточного понимания о среде, для которой вы что-либо разрабатываете, вам очень сложно будет делать действительно хорошие продукты.
Я пишу это с полным осознанием, потому что я пыталась пользоваться разными системами и вижу в чем заключается ключевая разница. Если вы не удовлетворены тем, что разрабатываете, если вам наплевать — меняйте свою сферу, потому что вы портите жизнь не только себе, но и людям, с которыми работаете, а еще и сам продукт.
Программное обеспечение представляет из себя десятки миллионов строчек кода, а количество разработчиков, стоящих за ними, достигает миллиона. Каждый программист, который занимается разработкой какого-либо продукта — это человек, у которого есть свои желания и стремления. Он так же покупает технику, как и его сосед юрист/врач/менеджер, водит машину, ходит в кино.
Когда я еще училась в универе, мой друг рассказал мне, как он сходил на конференцию, где был один из разработчиков платформы Windows Phone (мой друг как раз тогда занимался разработкой именно под WP). И когда он, воодушевленный, решил подойти к этому разработчику и задать ему пару вопросов, тот предложил сфотографироваться всем вместе и достал для этого новенький iPhone. Запал моего друга поутих. Так вот, значит ли это хоть что-нибудь?
Сейчас, когда мы уже на несколько лет впереди от этой ситуации, мы легко можем сказать, что этот разработчик просто сам не верил в собственный продукт, а если разработчик не верит в то, что разрабатывает — неудивительно, что это в итоге разваливается.
На мой взгляд, это немного не так. Однако и часть правды в этом так же есть.
Сложно сказать разработчику какой-нибудь космической программы попробовать ее использовать 24/7. Тут я скорее говорю о таких проектах, которыми мы в итоге действительно пользуемся, но по какой-то причине выбираем другой аналог, а не тот продукт, который или для которого мы что-то создаем.
Если вы разрабатываете приложение для автомобиля (карты, сбор статистики, такси), то вы должны уметь водить, потому что это позволит вам сформировать представление о том, как это все должно работать и насколько удобно пользоваться создаваемым вами продуктом другим людям в реальной жизни. Пишите какую-то операционную систему — пользуйтесь ей. Пишите приложения под iOS, используйте iPhone, пишете под Android — используйте Android.
Вы можете сказать, что все это неважно, ведь разработчик зачастую видит только строки кода и задачи в канбане. Какая ему разница, как работает то, что он создает, это задача уже архитектора и проектного менеджера, который пихает задачи и вообще кого угодно, но не его... Задача разработчика — писать код и чтобы его код не падал. И да, это тоже сработает, однако, к сожалению, если вы не имеете достаточного понимания о среде, для которой вы что-либо разрабатываете, вам очень сложно будет делать действительно хорошие продукты.
Я пишу это с полным осознанием, потому что я пыталась пользоваться разными системами и вижу в чем заключается ключевая разница. Если вы не удовлетворены тем, что разрабатываете, если вам наплевать — меняйте свою сферу, потому что вы портите жизнь не только себе, но и людям, с которыми работаете, а еще и сам продукт.
Post #64
1.77K
Жив хоть кто? Я тут собираюсь пробраться на парижский митап мобильных разработчиков. А то тут гуляла по диснейленду и приложение для него меня, мягко говоря, расстроило:С
Post #63
1.64K
Post #62
1.68K
В 2019 ничего не изменится?
За все время я успела поработать на разных проектах, в разных компаниях, с разными людьми. Каждый мой проект значил для меня много, я приходила на него с конкретной целью и, чаще всего, уходила, когда вбирала в себя все, что он мне мог бы дать.
Есть с десяток статей о том, какие разработчики безответственные и какие менеджеры дураки. Но переходя из компании в компанию, сталкиваясь с разным ведение процессов и взаимодействием людей, начинаешь понимать, что, по факту, менеджеры вводят новые методики, разработчики вводят новые подходы, но очень редко, когда они действительно знают, что делают. Зачастую, это бывает так: мы введем agile потому что я был на конференции и там сказали что это прям классно. И не важно, что та компания занималась разработкой приложения, которое продает пиццу, а мы делаем интерфейс для беспилотника.
У разработчиков так же, все кричат Kotlin, Dagger, RxJava!! А почему бы не запихнуть все это в проект и не важно, что Dagger мы вставим по шаблонам, которые никто так до конца и не понял, а как работает многопоточность из коробки вообще видимо не важно, а если заглянуть под капот Kotlin — польются кровавые слезы (хотя в последнее время стало явно лучше).
И только в очень редких случаях можно встретить людей, которые действительно понимают, что делают. Но, как правило, начинали они все с того же, что я описала выше.
Очень сложно сделать что-то с первого раза, без какого-либо опыта, чтобы оно сразу зашло, взлетело. Люди приходят на проект, от них ждут, что они сделают его лучше, но они учатся на нем и если все идет не по плану, они легко могут просто свалить. А вы со своим проектом останетесь у разбитого корыта.
Сейчас слишком много людей, которые хотят отвечать одновременно за все и ни за что. Они хотят кричать, что это они придумали и сделали, но если что не так, то просто отстраняются. Именно потому очень ценны люди, которые могут вытащить проект с самого дна, потому что мало кто будет даже просто пытаться.
Потому, если вы думаете, что все пошло не по плану и вам хочется уйти прямо сейчас, подумайте несколько раз о том, что вам дал этот проект и что он еще мог бы дать (тут я имею в виду даже не деньги, а скорее опыт и эмоции, которые вы получаете от работы). Потому что любое приложение, софт, система — написана людьми. Это целая команда, не только разработчики, но и аналитики, менеджеры, тестировщики. И если что-то не так с командой, если что-то не так с руководством — каждый начинает это чувствовать и проект разваливается.
За все время я успела поработать на разных проектах, в разных компаниях, с разными людьми. Каждый мой проект значил для меня много, я приходила на него с конкретной целью и, чаще всего, уходила, когда вбирала в себя все, что он мне мог бы дать.
Есть с десяток статей о том, какие разработчики безответственные и какие менеджеры дураки. Но переходя из компании в компанию, сталкиваясь с разным ведение процессов и взаимодействием людей, начинаешь понимать, что, по факту, менеджеры вводят новые методики, разработчики вводят новые подходы, но очень редко, когда они действительно знают, что делают. Зачастую, это бывает так: мы введем agile потому что я был на конференции и там сказали что это прям классно. И не важно, что та компания занималась разработкой приложения, которое продает пиццу, а мы делаем интерфейс для беспилотника.
У разработчиков так же, все кричат Kotlin, Dagger, RxJava!! А почему бы не запихнуть все это в проект и не важно, что Dagger мы вставим по шаблонам, которые никто так до конца и не понял, а как работает многопоточность из коробки вообще видимо не важно, а если заглянуть под капот Kotlin — польются кровавые слезы (хотя в последнее время стало явно лучше).
И только в очень редких случаях можно встретить людей, которые действительно понимают, что делают. Но, как правило, начинали они все с того же, что я описала выше.
Очень сложно сделать что-то с первого раза, без какого-либо опыта, чтобы оно сразу зашло, взлетело. Люди приходят на проект, от них ждут, что они сделают его лучше, но они учатся на нем и если все идет не по плану, они легко могут просто свалить. А вы со своим проектом останетесь у разбитого корыта.
Сейчас слишком много людей, которые хотят отвечать одновременно за все и ни за что. Они хотят кричать, что это они придумали и сделали, но если что не так, то просто отстраняются. Именно потому очень ценны люди, которые могут вытащить проект с самого дна, потому что мало кто будет даже просто пытаться.
Потому, если вы думаете, что все пошло не по плану и вам хочется уйти прямо сейчас, подумайте несколько раз о том, что вам дал этот проект и что он еще мог бы дать (тут я имею в виду даже не деньги, а скорее опыт и эмоции, которые вы получаете от работы). Потому что любое приложение, софт, система — написана людьми. Это целая команда, не только разработчики, но и аналитики, менеджеры, тестировщики. И если что-то не так с командой, если что-то не так с руководством — каждый начинает это чувствовать и проект разваливается.
Post #60
1.56K
Оу, ну ладно-ладно, я все поняла, только технологии, код и хардкор. Те, кто ждет бьюти блоги, вы там поосторожнее, а то от мужественности своего блога в один прекрасный момент я могу слететь с катушек и запилить сто слоев туши. Вот будет нежданчик (*^ω^*)
Post #59
1.46K
Этот год выдался довольно интересным. Я многому научилась, многое сделала, разные люди окружали меня, вдохновляли или, наоборот, вызывали отвращение. У меня сформировались более четкие цели на будущее и я очень рада этому, потому что когда нет конкретных целей, любые движения превращаются в мельтешение. Непонятно, что и зачем ты делаешь. Я давно хотела создать канал, но буквально несколько месяцев назад я не могла даже сформулировать, зачем он мне и как я буду его вести. Сейчас же это представление тоже до сих пор формируется. Потому на этот счет я решила спросить вас:)
Post #57
1.51K
#shkryaba
В этом году это будет моей последней статьей. Она уже давно у меня лежала и, надеюсь, кому-нибудь она сэкономит время. Итак, давайте погрузимся в это чудесное приключение по получению уникального идентификатора устройства. С наступающим!:)
В этом году это будет моей последней статьей. Она уже давно у меня лежала и, надеюсь, кому-нибудь она сэкономит время. Итак, давайте погрузимся в это чудесное приключение по получению уникального идентификатора устройства. С наступающим!:)
Post #56
1.73K
Думаю запилить статью о том, как работает ProGuard. Оказывается, до сих пор многие бояться даже на него смотреть и в лучшем случае пользуются его дефолтной реализацией.
Post #55
1.64K
Сегодня поговорим о стандартной безопасности клиент-серверных приложений, которые получают свои json-чики и парсят их во view. Итак, что мы можем сделать чтобы защитить свое клиент-серверное приложение?
Вообще здесь всего два пункта, на которые следует обратить внимание:
1. Идентификация и проверка пользователя как на клиенте, так и на сервере.
Идентификация пользователя включает в себя сбор данных безопасности с использованием клиентского программного обеспечения и предоставление этих данных серверу. Данные безопасности - это идентификатор пользователя, пароль и, необязательно, маркер безопасности.
2. Предотвращение несанкционированного доступа к приложению или его функциям.
После того, как пользователь идентифицирован на клиенте и сервере, права доступа этого пользователя должны быть определены, а приложение защищено в самом приложении. Обеспечение транзакции и ее функций является ответственностью разработчика приложений.
Конечно, я говорю это так что вот, смотрите, если вы будете следовать этим двум пунктам, то вы будете в безопасности. Классно то как!
Конечно же нет. Вы будете обмениваться токенами с сервером, токен вам придется где-то хранить, вы можете шифровать все это перешифровать, но в итоге, если появится человек, достаточно заинтересованный во взломе конкретно вашего приложения. Он вытащит из него все. Вы можете только максимально усложнить ему задачу. Это как с двумя дверьми. Первая выглядит вполне себе миленько, но когда злоумышленник вскрывает ее, его встречает бронебой и он такой: неее, пожалуй я залезу к твоему соседу Пете...
Полезный ресурс для защиты вашего клиент-серверного приложения
Nsoftware SecureBlackbox 16: Securing Your Client-Server or Multi-Tier Application Introductory article about security and encryption in distributed applications. Вообще здесь всего два пункта, на которые следует обратить внимание:
1. Идентификация и проверка пользователя как на клиенте, так и на сервере.
Идентификация пользователя включает в себя сбор данных безопасности с использованием клиентского программного обеспечения и предоставление этих данных серверу. Данные безопасности - это идентификатор пользователя, пароль и, необязательно, маркер безопасности.
2. Предотвращение несанкционированного доступа к приложению или его функциям.
После того, как пользователь идентифицирован на клиенте и сервере, права доступа этого пользователя должны быть определены, а приложение защищено в самом приложении. Обеспечение транзакции и ее функций является ответственностью разработчика приложений.
Конечно, я говорю это так что вот, смотрите, если вы будете следовать этим двум пунктам, то вы будете в безопасности. Классно то как!
Конечно же нет. Вы будете обмениваться токенами с сервером, токен вам придется где-то хранить, вы можете шифровать все это перешифровать, но в итоге, если появится человек, достаточно заинтересованный во взломе конкретно вашего приложения. Он вытащит из него все. Вы можете только максимально усложнить ему задачу. Это как с двумя дверьми. Первая выглядит вполне себе миленько, но когда злоумышленник вскрывает ее, его встречает бронебой и он такой: неее, пожалуй я залезу к твоему соседу Пете...
Полезный ресурс для защиты вашего клиент-серверного приложения