social.stefan-muenz.de
Die #Bewertung eines Testergebnisses am Beispiel #Corona
Erschreckend fand ich die Aussage, dass selbst viele Ärzte das #Testergebnis nicht richtig einschätzen können. Habe gehört, dass Arbeitgeber einmal pro Woche einen kostenlosen Test zur Verfügung stellen sollen. Hat von euch schon jemand einen Test von seinem Arbeitgeber bekommen?
#Gesundheit #Test #Statistik #Mathematik #Wahrscheinlichkeit #covid-19 #Pandemie #Wissen
Viele Menschen leiden unter einer differenzierten #Meinung ;)
#Querdenker #Corona #Politik #Demokratie #Gesundheit #Masken #Korruption #Wahlen #Wahlkampf
Viele Menschen leiden unter einer differenzierten #Meinung ;)
#Querdenker #Corona #Politik #Demokratie #Gesundheit #Masken #Korruption #Wahlen #Wahlkampf
"Wer hierfür abstimmt, dem muss die Hand abfallen!" - Scharfe Oppositions-Kritik zum IfSG
https://redirect.invidious.io/watch?v=gDk6bbYUOv0
Die Corona-Notbremse mit verbindlichen Regeln zur Bekämpfung der sogenannten "dritten Welle" auf bundesweiter Ebene hat im Bundestag zu einem heftigen Schlagabtausch geführt. Die Opposition kritisierte am Mittwoch vor der entscheidenden Abstimmung im Plenum unter anderem erhebliche Grundrechtseinschränkungen. AfD, Linke und FDP stimmten schließlich mehrheitlich dagegen, die Fraktion der Grünen enthielt sich.
#Abstimmung #Opposition #Kritik #IfSG #Corona-Notbremse #Corona #Notbremse #Bekämpfung #dritteWelle #Bundestag #Schlagabtausch #Plenum #Grundrecht #Grundrechtseinschränkungen #AfD #Linke #FDP #Fraktion #Grüne
Bundesgesetz verhindert Denken von Alternativen
Diese Ideenlosigkeit ist erschütternd
Für das Land der Dichter und Denker ist das ein absolutes Armutszeugnis. Mehr als ein Jahr fällt der Politik in Deutschland nichts anderes ein, als die Kultur einfach aus dem Leben der Menschen zu verbannen.
Nach dem gestern beschlossenen Infektionsschutzgesetz soll das auch so bleiben. Alle hervorragenden Hygienekonzepte, oft mit viel Engagement und wissenschaftlicher Unterstützung umgesetzt, werden einfach eingestellt.
Selbst das Pilotprojekt in Berlin, das zeigte, niemand von 1000 Besuchern in der Berliner Philharmonier steckt sich an, wenn alle sich an die Regeln halten, darf nicht weiterlaufen. Die Appelle der Kultursenatoren Klaus Lederer in Berlin und Karsten Broste aus Hamburg wenigstens Open Air Veranstaltungen zu erlauben, haben nicht gefruchtet. Wie will die Politik mit so einer Politik durch den beginnenden Sommer kommen und im September Wahlen gewinnen?
Maria Ossowski stellt sich in ihrem Podcast im Inforadio die Frage, ob sämtliche Politiker ihre kulturelles Verantwortungsbewußtsein verloren haben, wenn sie nur noch an das Offenhalten von Baumärkten denken, die Kultur aber nicht mehr im Blick haben. Und das, obwohl die Kuturstaatsministerin Monika Grütters Gelegenheit gehabt hätte, sich direkt bei der Kanzlerin für eine andere Politik einzusetzen. Seit Wochen laufen die Kulturverbände gegen die undifferenzierte Politik an, bisher vergeblich.
So bleibt der Kommentatorin zum Schluss nur Ironie oder ist es schon Zynismus, wenn sie den einsamen Hinterhofgeiger als letzte erlaubte kulturelle Veranstaltung empfiehlt, vorausgesetzt alle ZuhörerInnen halten sämtliche Hygienevorschriften ein und vermeiden durch Fenster putzen oder Müll wegbringen den Eindruck, es würde sich um Kultur handeln ...
Selbst CDU Politkern, die das Gesetz gestern gegen alle Oppositionsparteien beschlossen haben, fällt es inzwischen schwer, darin noch etwas sinnvolles zu sehen. So hätte sich der hessische CDU-Ministerpräsident in der gestrigen Corona-Sondersendung "an vielen Stellen andere Regelungen" gewünscht. Die "kritisierte Vielfalt" wird es nicht mindern, denn weiterhin bleibt das Damoklesschwert der Inzidenzwert im jeweiligen Landkreis, der sich vom Nachbar-Landkreis beliebig unterscheiden kann. Niemandem wurde durch das Gesetz geholfen, nur die föderale Struktur der Bundesrepublik wurde beschädigt.
Mehr dazu in dem Podcast von Maria Ossowski im Inforadio https://www.inforadio.de/programm/schema/sendungen/kultur/202104/21/554177.html
Link zu dieser Seite: https://www.aktion-freiheitstattangst.org/de/articles/7618-20210422-bundesgesetz-verhindert-denken-von-alternativen.htm
Link im Tor-Netzwerk: nnksciarbrfsg3ud.onion/de/articles/7618-20210422-bundesgesetz-verhindert-denken-von-alternativen.htm
Tags: #Corona #Kultur #Freizeit #Infektionen #Dichter #Denker #Philharmonie #Kuturstaatsministerin #Outdoor #Schließung #Psyche #Medien #Zensur #Transparenz #Informationsfreiheit #Gesundheit #Diskriminierung #Ungleichbehandlung #FfF #Verhaltensänderung #Gesundheitsdaten #Freizügigkeit
Check in with #CCTG. Version 2.0.3.0 is now available through our repository as an automatic update!
The update contains not only check-in functionality – allowing you to create as well as check in to events and locations via QR codes –, but also reduces the APK size by more than 10 megabytes, fixes remaining visual bugs on Android Lollipop, and warns users on their home screen if Battery Optimizations are not correctly disabled.
We hope you enjoy this release, stay safe.
Keine Meldepflicht für positive Corona-Tests an Schulen | BR24
Prima!Schon vergangene Woche hatte das Bayerische Kultusministerium eine Erhebung der Zahlen abgelehnt, mit dem Hinweis, dass der bürokratische Aufwand für die Schulen zu groß sei. Dabei bleibt es derzeit, teilt die oberste Schulbehörde dem BR auf Anfrage mit.Ach was!
#corona #BayernKeine Meldepflicht für positive Corona-Tests an Schulen
Wie viele Schüler testen positiv auf das Coronavirus? Man weiß es nicht. Zwar müssen Kinder und Jugendliche seit der Rückkehr aus den Osterferien zweimal pro Woche einen Selbsttest machen. Doch die Schulen müssen das Ergebnis nicht melden.www.br.de
Schon vergangene Woche hatte das Bayerische Kultusministerium eine Erhebung der Zahlen abgelehnt, mit dem Hinweis, dass der bürokratische Aufwand für die Schulen zu groß sei. Dabei bleibt es derzeit, teilt die oberste Schulbehörde dem BR auf Anfrage mit.Ach was!
Wie viele Schüler testen positiv auf das Coronavirus? Man weiß es nicht. Zwar müssen Kinder und Jugendliche seit der Rückkehr aus den Osterferien zweimal pro Woche einen Selbsttest machen. Doch die Schulen müssen das Ergebnis nicht melden.www.br.de
Vor einem Jahr hatte ich schon einmal Vermutungen angestellt. Schauen Sie mir zu Ihrem Vergnügen in diesem Artikel zu, wie ich meine Irrtümer von damals auseinandernehme – und direkt neue Thesen aufstelle.krautreporter.de
BfDI wrote the following post Tue, 20 Apr 2021 08:09:05 +0200
Content warning: Bei mir in der Firma hat sich jemand infiziert, mit dem ich dienstlich quasi täglich Kontakt habe. Man wird nicht mal informiert, niemand erkundigt sich, wer Kontaktpersonen gewesen sein könnte, man erfährt es nur über Flurfunk. Kollegen trauen sich nicht
#politik #politikversagen #corona #covid19 #tote #gedenktag #einkerzen #twitterKritik am Corona-Gedenktag #Einkerzen statt #Lichtfenster
»Zündet sie doch selber an«: Mit Protesten und Hohn reagieren Twitter-Nutzer auf den Vorschlag der Ministerpräsidenten, der Coronatoten mit einer Kerze im Fenster zu gedenken. Die Aktion bleibt nicht nur digital.
- https://www.spiegel.de/panorama/gesellschaft/einkerzen-protest-gegen-den-corona-gedenktag-auf-twitter-a-017afb9e-3819-4391-bd9f-7b78f9f9e349
#Sicherheit in der Luca-App und von #OpenSource allgemein
Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160
Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java
Teil 1:public boolean isUsingTestingCredentials() {return Objects.equals(firstName.getValue(), "John")&& Objects.equals(lastName.getValue(), "Doe")&& Objects.equals(phoneNumber.getValue(), "+4900000000000")&& Objects.equals(email.getValue(), "john.doe@gmail.com");}
Teil 2:boolean isValidPhoneNumber(String phoneNumberString) {if (isUsingTestingCredentials()) {return true;}try {...
Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.
Sicherheitsverständnis bei Open-Source
Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.
Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed
Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).
Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).
Was ist hier das Problem?
Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.
Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.
Insgesamt also alles sehr schlecht!
Wie kann ich das besser machen?
1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.
2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.
3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programmDie #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit i...
Die #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit im Code. Hart kodierte Accountdaten in der Luca-App, die die Prüfung der Telefonnummer übergehen https://i.imgur.com/2WmTdVE.pngpod.geraspora.de
#Sicherheit in der Luca-App und von #OpenSource allgemein
Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160
Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java
Teil 1:public boolean isUsingTestingCredentials() {return Objects.equals(firstName.getValue(), "John")&& Objects.equals(lastName.getValue(), "Doe")&& Objects.equals(phoneNumber.getValue(), "+4900000000000")&& Objects.equals(email.getValue(), "john.doe@gmail.com");}
Teil 2:boolean isValidPhoneNumber(String phoneNumberString) {if (isUsingTestingCredentials()) {return true;}try {...
Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.
Sicherheitsverständnis bei Open-Source
Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.
Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed
Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).
Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).
Was ist hier das Problem?
Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.
Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.
Insgesamt also alles sehr schlecht!
Wie kann ich das besser machen?
1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.
2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.
3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programmDie #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit i...
Die #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit im Code. Hart kodierte Accountdaten in der Luca-App, die die Prüfung der Telefonnummer übergehen https://i.imgur.com/2WmTdVE.pngpod.geraspora.de
public boolean isUsingTestingCredentials() {return Objects.equals(firstName.getValue(), "John")&& Objects.equals(lastName.getValue(), "Doe")&& Objects.equals(phoneNumber.getValue(), "+4900000000000")&& Objects.equals(email.getValue(), "john.doe@gmail.com");}boolean isValidPhoneNumber(String phoneNumberString) {if (isUsingTestingCredentials()) {return true;}try {...
Die #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit im Code. Hart kodierte Accountdaten in der Luca-App, die die Prüfung der Telefonnummer übergehen https://i.imgur.com/2WmTdVE.pngpod.geraspora.de
#Sicherheit in der Luca-App und von #OpenSource allgemein
Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160
Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java
Teil 1:public boolean isUsingTestingCredentials() {return Objects.equals(firstName.getValue(), "John")&& Objects.equals(lastName.getValue(), "Doe")&& Objects.equals(phoneNumber.getValue(), "+4900000000000")&& Objects.equals(email.getValue(), "john.doe@gmail.com");}
Teil 2:boolean isValidPhoneNumber(String phoneNumberString) {if (isUsingTestingCredentials()) {return true;}try {...
Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.
Sicherheitsverständnis bei Open-Source
Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.
Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed
Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).
Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).
Was ist hier das Problem?
Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.
Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.
Insgesamt also alles sehr schlecht!
Wie kann ich das besser machen?
1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.
2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.
3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
Ab einer Inzidenz von 200 sollen nach der geplanten Notbremse Schulen und Kitas schließen. Doch der Wert bezieht sich auf die Gesamtbevölkerung - bei Kindern liegt er oft höher.www.zdf.de
Die Corona-Verordnungen des Landes passen wir immer wieder an die aktuelle Infektionslage an. Hier finden Sie einen Überblick der aktuellen Änderungen.www.baden-wuerttemberg.de
16 #Demos in 16 #Bundesländer unter dem #Motto „Es reicht!“
Live aus #Berlin
#Corona #CoroNazis #GG #Grundrechte
Die CWA wird massiv erweitert. Für mich der richtige Ort, um Check-in und Nachweise vor zuhalten.Die Corona-Warn-App wird aufgerüstet
Schnelltest-Ergebnisse, Impfnachweis und Check-In-Funktion: Die Corona-Warn-App wird massiv aufgemöbelt. Ein Überblick.www.tagesspiegel.de
[/bookmark]
[/bookmark]
Dass ausgerechnet der nun in der Kritik stehende Richter für dieses Verfahren zuständig war, ist offenbar kein Zufall. Wie die »Thüringer Allgemeine« berichtet, soll eine Rechtsanwältin in einer Telegram-Gruppe für eine solche Klage gezielt Klägerinnen und Kläger gesucht haben, deren Kinder Nachnamen mit den Anfangsbuchstaben B, E, F, H, I, J, L, Q, R, S, T, U, V und X haben. Es sind laut der Zeitung genau jene Anfangsbuchstaben, für die der Einzelrichter laut dem Geschäftsverteilungsplan des Amtsgerichts zuständig ist.#corona #covid19 #fckafd
Spiegel Online Schlagzeilen (inoffiziell) wrote the following post Tue, 13 Apr 2021 15:15:18 +0200
