Frage

Diese Frage kam in unserem Projekt:

Die Sicherheit arbeitet jetzt unter HTTPS mit einem MobileSecurity-Test (XSRF usw.), der App-Authentizität für Android enthält. Unsere Adapter benötigen kein Benutzer / Pass-AUTH, sodass keine anderen Bereiche, Authentifizierung oder Anmeldemodule konfiguriert sind. Die App kann sofort nach WL.Client.CONNECT-Adapter-Prozeduren aufrufen.

Was ist das Arbeitslicht auf der Serverseite, um Serverseiten-JavaScript-Codes-Injektionsangriffe zu verhindern?

Details zu dieser Art von Angriff: http://media.blackhat .com / BH-US-11 / Sullivan / BH_US_11_SULIVAN_SERVER_DE_WP.PDF

Mit anderen Worten, (obwohl schwierig) angenommen werden kann, dass jemand unsere APK nutzen konnte, um eine neue APK zu erstellen, die den Arbeitslicht-Auth / Sicherheitsmechanismus täuschen konnte. Wir sind dann anfällig für einen serverseitigen JavaScript-Code-Injektion anfällig?

Es löst ziemlich viel auf die Frage, wenn alle Parameter für alle WL-Serveranrufe aus ausgewertet und von Text in JavaScript-Objekten auf maximal sichere Weise in JavaScript-Objekte analysiert werden. Wenn niemals die Möglichkeit besteht, dass der Parametertext als JavaScript-Code ausgeführt werden kann auf dem server?

Wenn ja, gibt es zusätzliche Arten von möglichen Angriffen, an denen die WL-Server-JavaScript-Implementierung dagegen gesichert ist, dass wir möglicherweise nicht einmal wissen?

War es hilfreich?

Lösung

Parameter werden von Adaptern als String / Int / Bool / Array usw. empfangen

Ein weiterer Schutzstück WL Adapter Framework hat ein Verpackungsadapterantwort im Kommentar.Z.B.Wenn Ihr Adapter {VAL: 1} zurückgibt, enthält der eigentliche Antwortkörper

generasacodicetagpre.

Dies verhindert, dass JS ausgeführt wird, auch wenn sie von einem Client automatisch ausgewertet wird, z.Bei Beladung von einem generationsporticetagcode

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top