Założenia techniczne aplikacji mobilnej

Haha, dobre pytanie, muszę sam odtworzyć temat.
Aaa, chodziło o to, że klient Androidowski pisany w HTML i JS mógłby okazać się nieodporny na ataki XSS, a to z kolei było odpowiedzią na pytanie, co ma klient do błędów bezpieczeństwa. :)

Ale, wracajć do tematu. To jak, ktoś chętny pisaniu wsparcia Androida dla silnika?

Nie znam RUbiego, wiec checi mozemy sobie wsadzic.

CZegoś tu nie rozumiem. Może jestem głupi ale: Dawid pisze, że boi się klientów, zwłaszcza na Andka, bo jeśli będzie źle napisany to dziury będą i jakiś niegrzeczny pan lub pani będą se mogli zrobić dużo, w dodatku jeśli coś będzie działąło nie tak to Dawid po dziobie dostanie. Z drugiej strony, jak rozumiem, na Githubie dostępny jest kod źródłowy, który pozwala niegrzecznym panom na zrobienie aplikacji do wynoszenia co się da. Wnioskuję to z obaw o źle napisanego klienta. Innymi słowy z jednej strony mamy otwarte źródło, z drugiej nie wiadomo na jaką cholerę skoro po pierwsze klientó nie tworzyć, bo można rozsadzić server jeśli stworzy go idiot, z drugiej niegrzeczny pan / pani moze w dodatku zrobić świadome kuku. W takim razie po co ta otwartość?
Z drugiej strony wydaje mi się, że Dawid obawia się głupoty programistów tj. sam tworzy coś, z drugiej boi się, że inni zrobią gorzej, czyt. są w jakiś sposób głupsi albo przyłożą się mniej do roboty. Tu znowu nie rozumiem idei otwartego źródła.

Nie jest to jedyna ani nawet główna przyczyna, co podkreślałem.
Nie, źle napisany klient nie zaszkodzi serwerowi. Źle napisany klient zaszkodzi użytkowniowi.
Jeśli pojawiłaby się np. luka XSS, to możliwe byłoby spreparowanie wpisu na forum czy wiadomości prywatnej, która wykradłaby token sesji użytkownika i pozwoliłą robić cokolwiek z jego kontem etc.
Oczywiście, nie zakładajmy od razu, że klient zewnętrzny oznacza takie błędy. To tylko możliwość, a nie pewnik.

Coś mnie tu zaczyna niepokoić. Jeśli publicznie dostępny jest kod, który umożliwia stworzenie, swiadome czy nie, czegoś, co może zrobić kuku użytkownikom to trochę lipa i po mojemu przydałoby się jakoś przed tym zabezpieczyć, a jeśli się nie da to zamknąć kod, bo fakt, że klient autorski jest bezpieczny robi się cośkolwiek pozornym uspokojeniem. Kto zaręczy, że jakiś ktoś, komu zalazłeś za skórę nie tworzy czegoś do robienia użytkowników w jajo?

Ale to dotyczy wszystkiego. Dziurawy może być każdy klient każdej platformy - czy to Elten, czy to Twitter.

No dobra tyle, że o ile wiem, nie da stworzyć klienta twittera, któryby hm... nie wiem, przechwytywał onta użytkowników czy coś, bo padłoby to szybciej niż powstało.

W sensie jemu chodzi o coś takiego, że na przykład zrobię ja sobie mini język skryptowy, na przykład
{
"GetToken":"Nuno69"
}
I wyślę komuś wiadomość z takim ciągmiem znaków, klient ogarnie, że ma przesłać mi jego token logowania i vuala! Ale tak można robić Dawidzie ze wszystkim.

Tak. Źle napisany klient Twittera da pełny dostęp do konta Twittera przy spreparowaniu odpowiedniego tweeta czy czego tam. Ryzyko tym większe, im bardziej skryptowy język - dużo łatwiej o coś takiego w JS czy w Rubym czy w językach z rodziny C.

Nie chcę ci nic móić, ale jak ktoś jest debilem i bedzie używać klienta Mohammet Elten stwozony przez spółkę Al Muallim Jarasool LLC to tak będzie. Userzy też muszą mieć mózg na karku

Ale moment. Chcecie powiedzieć, że odpowiedni skrypt do twittera jest w stanie zrobić kuku innym użytkownikom? Toż wtedy afera typu wyciek kilku tysięcy kont to pikuś w porównaniu z tym, co możnaby takim skryptem osiągnąć. Jakoś mimo wszystko afery związane z wyciekami są więc wnioskuję, że jakoś się nie rozumiemy. W czym więc tkwi mój błąd?

NO tak, bo ja mogę przechwycić czyjś klucz autoryzacyjny i mieć dostęp do jego konta

To jak to się dzieje, że jakoś nie ma takich potężnych afer z wyciekami setek tysięcy kont? Skoro można przechwycić to czemu się nie przechwytuje wszystkiego co ino się do?

No bo żaden mainstreamowy klient nie przechwytuje, a klienty typowo malicious są szybko usuwane.

Na pewno są klienty dziurawe. Tyle, że te znane, duże są sprawdzane, przemyślane, a nie pisane w notatniku w tydzień.

W jakim sensie usuwane?

Ja się tu wypowiem w kilku kwestiach.

Podsumowanie dla nietechnicznych.
1. Elten nie jest otwarty, wbrew temu co mówi Dawid.
2. Przejście na nową stronę korzystającą z nowego API będzie bezpieczniejsze, obecna strona jest niebezpieczna (bardzo).
3. XSS nie taki straszny, jak go malują.
4. Albo akceptujemy nieoficjalne klienty albo nie, ale w naszym przypadku nie jest raczej hipokryzją.
5. Ustalmy coś w związku z tą otwartością.



1. Kwestia otwartości Eltena. Jeżeli licencja Eltena jest taka, jak Dawid mówi, tj. można poprawiać, nie można robić klonów, nie wiele ma to z open source wspólnego. Nie pamiętam, jak typ licencji "czytać możesz, ale wykorzystywać niekoniecznie" się nazywał, ale to jest coś tego typu. Żeby nie było, ja rozumiem, dla czego tak, ale nie nazywajmy tego open source.
2. Kwestia bezpieczeństwa. Tak na prawdę pisanie na nowoczesnym stacku jest bezpieczniejsze niż pisanie na lamp. Przez nowoczesny stack rozumiem frontend jako single page application, może server rendered, we frameworku typu React, Angular, Vue czy innym takim, backend w jakimś Node, Pythonie, Ruby, Go czy nowoczesnym, podkreślam, nowoczesnym php lub języku bazującym na JVM z nowoczesnym frameworkiem. LAMP to oczywiście stary stack typu Linux, Apache, My SQL, PHP. Na tym stoi z tego co wiem Elten, chyba z Nginxem zamiast Apache, ale to akurat ma w tym kontekście małe znaczenie. Taki stack ma kilka podstawowych problemów. Rzeczy typu najczęściej słaba struktura aplikacji i brak zastosowania rzeczy typu mvc, które im większa będzie apka tym większym będą problemem zostawmy, bo nie o tym tu. Skupmy się na problemach bezpieczeństa. A więc, po pierwsze, w php często pracujey na stringach, nie na objektach i szablonach, tak jak ma to miejsce w js/ruby/whatever. Przykład? generowanie htmla. W nowoczesnym, frontendowym frameworku piszemy na przykład.


a w poście
{author
Framework wie, że author w klamrach jest czymś w klamrach, z zewnątrz, i wyświetli w przeglądarce taki string, jaki dostanie co oznaczy, że jeżeli stringiem będzie , to właśnie się wyświetli (ale nie wykona). Innymi słowy, frameworkowi podajemy co on ma nam wyświetlić a on wiedząc, że to jest user input zrobi co trzeba. W php zato pisalibyśmy coś w rodzaju ' ' + jakas_funkcja(author) + ' ';
Gdzie jakas_funkcja ma sprawić, że w userze nie będzie "złych" znaków. Jak o niej zapomnimy, mamy xss. Podobnie z sql. W nowoczesnych bazach danych piszemy zapytania w stylu
select subject, content from articles where author_id=$1 i do funkcji wykonującej zapytania podajemy parametr id. Parametr id zawsze będzie tylko parametrem id, nawet jeżeli jakimś cudem znajdzie się w nim treść typu '; drop table users; O to zadba sql. W php znowu najczęściej bazowalibyśmy na stringach i ich łączeniu.
W jeszcze bardziej nowoczesnych bazach w ogóle nie używamy sqla tylko czegoś typu json, ale to już zupełnie inny temat. To by wymagało za dużo roboty, a przejście na parametry zostawiając starą bazę zdecydowanie mniej.

Podsumowując, frontend w react + api json + backend w czym tam jest aktualnie pisany jest bezpieczniejszy i jest mniejsza szansa na xss niż przy obecnej stronie (ostatnio sam tam jednego znalazłem i to za pierwszą próbą, więc jest ich pewnie mnustwo). Ponadto frameworki rozwiązują kilka innych roblemów, np. mniejsza podatność na xsrf gdy używamy komunikacji po application/json a nie zwykłych formularzach (zakładamy, że nie zepsujemy ustawień CORS) itp.


3. Padło tu wcześniej, że xss pozwala na dostęp do całej bazy użytkowników, co jest nie prawdą. Xss pozwala conajwyżej na uruchomienie kodu w kontekście użytkownika, który taki xss dostanie. W najgorszym wypadku, gdy np. xss będzie w tematach wiadomości (taki ostatnio był na stronie) teoretycznie możnaby zainfekować wszystkich, którzy korzystają z danego rozwiązania, w tym przypadku strony, ale tylko tych. Jak xss jest mniej oczywisty (treść wiadomości, post na forum, jakieś dziwne pole w profilu) infekcja nastąpi tylko u osób mających podatne urządzenie i czytających tę treść. Ponadto infekcja da dostęp tylko do treści, do których dostęp mają ci urzytkownicy.

4. Trzebaby ustalić, co z tym api i kto może mieć do niego dostęp. Albo idziemy w stronę Telegrama i dajemy dostęp wszystkim i niech piszą, ich program, ich sprawa, albo nie dajemy go wcale. To trochę tak, gdyby Apple powiedzial, że nie pozwoli Microsoftowi napisać Ofice'a na Maca bo Office to jest taki dobry program, ludzie się przywiążą, Microsoft może porzuci i co wtedy? A tak poza tym to Office będzie pisany jako program zamknięty i my nie będziemy go potem mogli poprawiać, jak Microsoft porzuci. Brzmi absurdalnie, ale tak właśnie działa Elten. Smuci mnie bardzo, gdy w tym środowisku panuje taka hipokryzja. Jeszcze niedawno była afera o zamknięcie API Twittera dla nieoficjalnych klientów i Mój Pociąg, wcześniej o niedziałającego GW Connecta, a teraz Elten robi dokładnie to samo i to z kompletnie niezrozumiałych pobudek. Ja uważam, że jeżeli tak bardzo martwimy się o to API, musimy przyjąć politykę Telegrama (czyli klienty tak, ale tylko na GPL i albo bez Elten w nazwie albo z nazwą unofficial) i dać sobie spokuj. Jak się im będzie chciało to fajnie, tylko lepiej, jak nie, trudno. My potem będziemy sobie mogli robić swoje, a unofficial będą robić swoje. Może jedni od drugich podkradną pomysły, patrz cytowanie tweetów, załączanie obrazków czy retweet, których na Twitterze nie było a zostały wprowadzone do klientów jako hacki. Elten może iść swoją drogą (tak jak appki Twittera na iOs i Androida), nie zwwarając, czy są czy nie ma na te platformy klientów oficjalnych. Gdyby do tego wprowadzić logowanie do klientów pinem (tak jak na Twitterze kiedyś) albo przez oauth2, możnaby ładnie użytkownikom wyświetlić wcześniej informacje, że oto ten i ten nieoficjalny klient chce się do ciebie zalogować, jak mu pozwolisz, jest takie i takie ryzyko, tak przycisk, nie przycisk.

5. Podobnie z otwartym kodem. Albo idziemy w totalne open source (z pushem na każdy commit względnie każdą betę) albo nie twierdźmy, że Elten jest otwarty.

A, jeszcze coś.

Co do tomeckiego i klientów zewnętrznych, przechwycenie twoich danych jest możliwe na tej zasadzie, że autor klienta zagnieździ w nim kod lub klient będzie dziórawy i wyciekną dane użytkownikó danego klienta. Z racji, że większość korzysta z oficjalnych appek, a ta niewielka część używająca klientów to albo ludzie o specjalnych potrzebach (niewidomi) korzystający ze sprawdzonych dla siebie rozwiązań albo ludzie którzy raczej wiedzą, co instalują, żadko sę takie coś zdaża.

Co jeszcze do podatności w ogóle, Dawid nie jest nieom7lny i ośmielę się stwierdzić, że coś pisane nowocześniej będzie bezpieczniejsze od rzeczy obecnie pisanych przez Dawida.

Co do serializacji w Rubym, uważałbym, bardzobym uważał. Nie wiem, jak serializacja działą tam, ale w bardzo dużej ilości języków serializacja może i była szybka, ale miała różne dziwne problemy, od tych z kompatybilnością (między wersjami Runtime i architekturami) po te z bezpieczeństwem (użytkownik mógł zserializować sobie dane tak, że dołączył do nich swój sserializowany kod, bo niektóre rzeczy od serializacji na to pozwalały). Taki kod został zdeserializowany i uruchomiony przez serwer i... użytkownik miał nad serwerem pełną włądzę.

@mikolajholysz, a o różnicach między oprogramowaniem wolnym a otwartym słyszeli?

oczywiście, wolne jest od otwartego jeszcze bardziej otwarte, kwestia chociażby konieczności otwierania rzeczy,które na nim bazują itp.