| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
OneCypher
Anmeldungsdatum: 23.09.2007
Beiträge: 802
|
 Verfasst am: 30.10.2008, 13:19 Titel: Privat nicht wirklich vertraulich? |
 |
|
| Code: |
type _tresor
public:
oeffentlich as string
Declare Constructor ()
private:
darfkeinersehen as string
end type
Constructor _tresor()
oeffentlich = "Der Chef ist Klasse!"
darfkeinersehen = "Ich mag meinen Chef nicht!"
end constructor
type _einbruch
oeffentlich as string
versteckt as string
end type
dim tresor1 as _tresor
dim einbruch as _einbruch ptr
print tresor1.oeffentlich
einbruch = cast(any ptr, @tresor1)
print einbruch->versteckt
sleep
|
irgendwie hab ich mir verhofft nicht an mein privates "darfkeinersehen" herranzukommen :-/
obwohl ich noch nicht genau weiss obs in C++ nicht auch so funktioniert... |
|
| Nach oben |
|
 |
Elektronix
Anmeldungsdatum: 29.06.2006
Beiträge: 742
|
| Verfasst am: 30.10.2008, 14:17 Titel: |
|
|
Sollte eigentlich in C++ nicht gehen, daß Du den Zeiger ja auf "Any" umcastest. Das gibt es in C++ nicht. Nachdem "darfkeinersehen" an der gleichen Stelle im Type liegt wie "versteckt", hat es den gleichen Index, und so kannst Du eben darauf zugreifen.
_________________
Und die Grundgebihr is aa scho drin- DOS is jo nett. |
|
| Nach oben |
|
|
OneCypher
Anmeldungsdatum: 23.09.2007
Beiträge: 802
|
| Verfasst am: 30.10.2008, 15:22 Titel: |
|
|
| Das die Anordnung der Indexe der Variablen anscheinend die selben ist mir klar, aber darf das so sein? .. private-inhalte müssen ja nicht direkt verschlüsselt im arbeitsspeicher abgelegt werden, aber irgendwie hab ich mir ein quäntchen mehr "privatsphäre" gewünscht wenn ich bestimmte variablen als privat deklarieren... |
|
| Nach oben |
|
|
OneCypher
Anmeldungsdatum: 23.09.2007
Beiträge: 802
|
| Verfasst am: 30.10.2008, 15:25 Titel: |
|
|
| PS: Benutze ich kein CAST dann entsteht lediglich "Suspicious pointer assignment" beim kompilieren, was aber dem programm-ablauf auch nicht schadet... |
|
| Nach oben |
|
|
Elektronix
Anmeldungsdatum: 29.06.2006
Beiträge: 742
|
| Verfasst am: 30.10.2008, 16:34 Titel: |
|
|
| OneCypher hat Folgendes geschrieben: | | Das die Anordnung der Indexe der Variablen anscheinend die selben ist mir klar, aber darf das so sein? .. private-inhalte müssen ja nicht direkt verschlüsselt im arbeitsspeicher abgelegt werden, aber irgendwie hab ich mir ein quäntchen mehr "privatsphäre" gewünscht wenn ich bestimmte variablen als privat deklarieren... |
Naja, nobody and no programming language is perfect  .
Das private ist nur eine Anweisung an den Compiler, die Zugriffsrechte zu überprüfen. Im Maschinencode gibt es keine Unterscheidung zwischen private und public mehr.
Wenn Du einen Pointer setzt, fragt der Rechner auch nicht, ob das Zielobjekt Privat ist, sondern fragt nur stur die Adresse ab. Durch das Casten auf den Typ "Einbrecher", der keinen privaten Bereich enthält, hast du die privatsphäre aufgehoben. Das ist die Gefahr bei Typecasting und Any-Pointern.
Du kannst statt des Typecasts auf any auf einen Tresor-Pointer casten, dann bleibt der Privatbereich wahrscheinlich erhalten (vermute ich, habs jetzt nicht probiert).
Das "suspicious pointer assignment" ist nur eine Warnmeldung, weil der Pointer zur Laufzeit einen unzulässigen Wert annehmen könnte.
_________________
Und die Grundgebihr is aa scho drin- DOS is jo nett. |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 31.10.2008, 13:13 Titel: |
|
|
Ich glaube ihr betrachtet dies aus einer falschen Sicht 
Was du als "einbruch" bezeichnest ist doch eine Kopie des Type _tresor, also ein 'Schlüssel'.
Also nur mit dem richtigen Nachschlüssel komm ich auch an den Inhalt des Tresors, sonst:
| Code: | TYPE _tresor
PUBLIC:
oeffentlich AS String = "Der Chef ist Klasse!"
darfjedersehen AS String ="Ich mag meinen Chef!"
PRIVATE:
meingehalt As Double = 1234.56
darfkeinersehen AS String = "Ich mag meinen Chef nicht!"
END TYPE
TYPE _nachschluessel
oeffentlich AS STRING
versteckt AS STRING
END TYPE
DIM tresor1 AS _tresor
DIM nachschluessel AS _nachschluessel PTR
PRINT tresor1.oeffentlich
nachschluessel = CAST(Any PTR, @tresor1)
PRINT nachschluessel->versteckt
SLEEP |
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
OneCypher
Anmeldungsdatum: 23.09.2007
Beiträge: 802
|
| Verfasst am: 31.10.2008, 13:50 Titel: |
|
|
Ich wollte eher in hinblick auf den sicherheitsaspekt fragen ob das wirklich richtig implementiert ist, das private und public variablen innerhalb einer udt genauso in ihrer reihenfolge im speicher angeordnet bleiben als ob es keinen unterschied zwischen private und public gäbe.
Klar, wenn man die type nicht kennt, kann man auch nicht auf dessen private daten zugreifen.
Aber sobald man den aufbau kennt, kann man auf evtl. vertrauliche daten zugreifen... wie gesagt, ich rede nicht davon das sie verschlüsselt sein sollten, das wäre zuviel verlangt. Aber vom aspekt der vetraulichkeit von "privaten" daten, wäre es nicht eher sinnvoll private daten im speicher an einer logisch nicht nachzuvollziehende stelle im speicher abzulegen?
Will natürlich auch nicht die allwissenheit und allmächtigkeit der compiler entwickler angreifen! deswegen ist das jetzt erstmal "nur" eine frage... |
|
| Nach oben |
|
|
Elektronix
Anmeldungsdatum: 29.06.2006
Beiträge: 742
|
| Verfasst am: 31.10.2008, 14:01 Titel: |
|
|
| OneCypher hat Folgendes geschrieben: |
Aber sobald man den aufbau kennt, kann man auf evtl. vertrauliche daten zugreifen... wie gesagt, ich rede nicht davon das sie verschlüsselt sein sollten, das wäre zuviel verlangt. Aber vom aspekt der vetraulichkeit von "privaten" daten, wäre es nicht eher sinnvoll private daten im speicher an einer logisch nicht nachzuvollziehende stelle im speicher abzulegen? |
Theoretisch ja. Das würde aber bedeuten, daß der Compiler eine Funktion dazudichten muß, die die Speicherzuweisung für die privaten Daten übernimmt (macht normalerweise das Betriebssystem) und die Zugriffsfunktion entsprechend ergänzt. Der Programmieraufwand ist wohl unverhältnismäßig hoch.
_________________
Und die Grundgebihr is aa scho drin- DOS is jo nett. |
|
| Nach oben |
|
|
OneCypher
Anmeldungsdatum: 23.09.2007
Beiträge: 802
|
| Verfasst am: 31.10.2008, 15:20 Titel: |
|
|
Hmm.. wäre echt klasse wenn man es implementieren könnte das privat-deklarationen im speicher woanders angeordnet werden..
so muss ich es manuell machen:
| Code: |
type privatdaten
daten as string
end type
TYPE _tresor
PUBLIC:
oeffentlich AS STRING
DECLARE CONSTRUCTOR ()
PRIVATE:
darfkeinersehen AS privatdaten ptr
END TYPE
CONSTRUCTOR _tresor()
oeffentlich = "Der Chef ist Klasse!"
darfkeinersehen = new privatdaten
darfkeinersehen->daten = "Ich mag meinen Chef nicht!"
END CONSTRUCTOR
TYPE _einbruch
oeffentlich AS STRING
versteckt AS STRING
END TYPE
DIM tresor1 AS _tresor
DIM einbruch AS _einbruch PTR
PRINT tresor1.oeffentlich
einbruch = CAST(ANY PTR, @tresor1)
PRINT einbruch->versteckt
SLEEP
|
Und kann mir einer mal sagen warum ich mit new keinen string im speicher erzeugen kann?
" The NEW operator cannot be used with strings in 'darfkeinersehen = new string' "
Warum muss ich um einen String im speicher neu anzulegen eine type dafür bemühen?? |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 31.10.2008, 15:34 Titel: |
|
|
Hmm..
ich denke 'Private' ist hier nur gedacht direkte Zugriffe, a la "tresor1.darfkeinersehen" zu verhindern.
Das sind keine "vertraulichen" Daten und auch ein auslagern der Daten, aus der Type Reihenfolge in andere Bereiche, erfordert dann einen Pointer darauf, der auch wieder die Daten zugänglich macht  .
Ich sehe da keinen Unterschied zu anderen Programmiersprachen, es gibt bestimmt immer einen Weg an diese Daten zu gelangen.
| Code: | TYPE privatdaten
daten AS STRING
END TYPE
TYPE _tresor
PUBLIC:
oeffentlich AS STRING
DECLARE CONSTRUCTOR ()
PRIVATE:
darfkeinersehen AS privatdaten PTR
END TYPE
CONSTRUCTOR _tresor()
oeffentlich = "Der Chef ist Klasse!"
darfkeinersehen = new privatdaten
darfkeinersehen->daten = "Ich mag meinen Chef nicht!"
END CONSTRUCTOR
TYPE _einbruch
oeffentlich AS STRING
versteckt AS String ptr
END TYPE
DIM tresor1 AS _tresor
DIM einbruch AS _einbruch PTR
PRINT tresor1.oeffentlich
einbruch = CAST(ANY PTR, @tresor1)
PRINT *(einbruch->versteckt)
SLEEP |
... nur eine Frage des Nachschlüssels. 
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
Dominik
Anmeldungsdatum: 22.12.2004
Beiträge: 172
|
| Verfasst am: 02.11.2008, 13:59 Titel: |
|
|
Hi,
ich sehe es genauso wie volta.
"Private" hat nichts mit "Privatsphäre" etc. zu tun und ist auch nicht dafür geeignet, sensible Daten zu verschlüsseln.
"Private" dient ausschließlich dazu, zu verhindern, dass man den klasseninternen Funktionsablauf gefährdet. Diese Daten sind unsichtbar für andere Objekte, die nicht Teil der Klasse sind, damit diese die Daten nicht versehentlich ändern oder lesen, aber keinesfalls, um diese vor Crackern zu schützen.
So geht es zum Beispiel die Klasse PetOwner nichts an wie die Klasse Dog auf die Methode "eat" intern reagiert, aber wenn du den Hund durchleuchtest, siehst du es z.T. doch. |
|
| Nach oben |
|
|
Elektronix
Anmeldungsdatum: 29.06.2006
Beiträge: 742
|
| Verfasst am: 02.11.2008, 17:13 Titel: |
|
|
@Dominik
Richtig. Private und public sind Erfindungen der OOP. Die soll zwar in FB auch mal realisiert werden, aber so weit sind wir noch nicht.
OOP soll die Aktionen einzelner Objekte in der Realität nachempfinden. Die Deklaration "private" ermöglicht nur, da ein Objekt selbst entscheiden kann, welche seiner Daten wie und wann genutzt werden, und verhindert, daß fremde Objekte auf diese Daten sozusagen ohne Legitimation oder ohne Kontrolle zugreifen.
_________________
Und die Grundgebihr is aa scho drin- DOS is jo nett. |
|
| Nach oben |
|
|
AndT
Anmeldungsdatum: 02.04.2007
Beiträge: 481
|
| Verfasst am: 27.11.2008, 13:36 Titel: |
|
|
Äh warum so kompliziert wenn es auch einfach geht??
| Code: | type strenggeheim
private:
dim geheime_botschaft as string = "HALLO :)"
end type
dim as strenggeheim oops
' ein kleiner exploit der das unmöliche möglich macht...
dim as string exploit(1)
print exploit(2)
sleep |
_________________
Bis irgendwann...  |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 27.11.2008, 14:02 Titel: |
|
|
Wieso "einfach" ?
Zeigt doch nur das man sogar aus "versehen", durch einen Programmiererfehler, an die Daten kommen kann!
In einem größeren Prog, mit weiteren Strings, würde das so leicht nicht mehr funktionieren.
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
dreael
Administrator
Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)
|
| Verfasst am: 27.11.2008, 15:18 Titel: |
|
|
Zu dieser gesamten Diskussion: Private und Public sind typische Paradigmen aus der OO-Grundphilosophie und stellen die Grundlage für Information Hiding bzw. präsizer Dateneinkapselung dar. Als Benützer einer Klasse muss ich die Internas nicht zu kennen. Die Unterstützung von "private" beim Compiler garantiert mir, nicht versehentlich auf interne Ressourcen direkt zuzugreifen und gibt mir als Programmierer die Gewähr, Änderungen an der Klasse vornehmen zu können, ohne dass die Linker/Schnittstellen-Kompatibilität verloren geht.
Dateneinkapselung hat übrigens absolut nichts mit IT Security (Schutz von Informationen gegen unbefugtem Zugriff), wie ich es als Geschäftszweig meiner eigenen Firma praktiziere, zu tun!
_________________
Teste die PC-Sicherheit mit www.sec-check.net |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
