Veilige gebruikersinvoer

Ik heb veel berichten over berichten (en stapeloverloop) gelezen over het ontsnappen van personages en het ontsmetten van gebruikersinvoer, maar ik zou het allemaal willen koppelen en het een beetje specifieker maken voor het Android-platform. Dit is mijn omstandigheid:

Ik heb een Android-app die communiceert met een webservice via SOAP XML-berichten. Hier is een voorbeeld XML-bericht dat kan worden verzonden (ik laat de SOAP-envelop er omheen):


    user entered text
    
user entered text

Zoals je ziet, zijn er 2 plaatsen waar een gebruiker tekst kan invoeren in een formulier dat vervolgens in dit bericht wordt ingevoegd om naar de webservice te worden verzonden. Ik moet:
A) zorg ervoor dat het geldige xml en
is B) zorg ervoor dat het geen schadelijke SQL-inhoud bevat.

Are there any pre-included utilities in the Android API to escape invalid xml chars (such as &) that the user may have entered? (So that I can simply say "escapeXML(xmlstring);" or something like that)

Is er een manier om te controleren op schadelijke SQL (of een andere code-injectie) of moet dat worden afgehandeld op de server?

Als een kanttekening: ik zou bijna de voorkeur geven aan het feit dat de gebruiker alleen A-z, 0-9 en standaard interpunctie kon invoeren (om rare unicode-karakters te vermijden die soms niet eens kunnen worden gezien of geïnterpreteerd). Is er een goede manier om gebruikersinvoer te beperken tot een subset tekens?

Ik weet dat dit een paar vragen zijn die in één zijn ingebouwd, dus als je er maar een deel van kent, geef dan sowieso een antwoord en ik zal het graag overnemen of accepteren. Alvast bedankt voor alle hulp! (StackOverflow is waar ik kom wanneer ik veel te veel forumdiscussies heb opgebruikt en mezelf helemaal in de war heb gebracht over wat toepasselijk is in mijn omstandigheden)

 1
toegevoegd bewerkt
Bekeken: 32
de bron
ro ru fr es pt de hi bn ar kk tr
Ik vermoed dat je het waarschijnlijk zou kunnen beperken met regex, maar dat zou ik niet doen. Ten eerste beschermt het op die manier beperken helemaal niet tegen injectie (u hebt alleen basispupuation nodig). Ten tweede, als een van uw gebruikers een buitenlandse tekenset gebruikt (of zelfs probeert correct buitenlandse uitleenwoorden in te voeren), is het misschien een beetje miffed als hun invoer wordt geweigerd. Normaal gesproken zou u in plaats daarvan niet opgemaakte XML-store-entiteiten (klasse-instanties) moeten opslaan. Geparameteriseerde zoekopdrachten moeten zorgen voor SQL-injectie - u zult hier ook op cross-site-scripting moeten letten.
toegevoegd de auteur Clockwork-Muse, de bron
Zonder je cliënt te kennen, kan ik het niet met zekerheid zeggen, maar misschien gebruik je buitenlandse woorden vaker dan je denkt (zelfs als je ze niet goed 'spelt'). Zelfs als uw klant alleen in de VS werkt (meer afhankelijk van domein/locatie). Normaal gesproken gebruikt u bij het omgaan met SOAP een kader/bibliotheek die het bericht serialiseert/deserialiseert - uw code weet niet noodzakelijkerwijs zelfs dat het afkomstig was van een XML-bericht (en waarschijnlijk ook niet). Er zijn verschillende voor Java, weet niet over een Android-specifieke versie.
toegevoegd de auteur Clockwork-Muse, de bron
Welnu, ik weet dat we het niet over vreemde woorden zullen hebben, omdat het een app is die speciaal is geschreven voor een specifieke klant die alleen in de VS werkt. Ook dacht ik niet dat het beperken van de invoer tot tekst, cijfers en interpunctie de SQL-injectie zou voorkomen, maar eerder dat het de tekstlezer-vriendelijk zou houden (omdat de geest niet weet hoe een Control-teken moet worden "gelezen" bijvoorbeeld )
toegevoegd de auteur D.R., de bron

1 antwoord

De beste manier om met SQL Injection om te gaan, is het gebruik van geparametriseerde query's. Dit gebeurt aan de serverzijde. Al het andere is secundair, onnodig of nauwelijks krasjes aan de oppervlakte van het probleem.

Je zou deze moeten lezen:

Op Jeff Atwood's blog vind ik het leuk waar hij zegt:

Niet-geparametriseerde SQL is de GoTo-verklaring van databaseprogrammering.

3
toegevoegd
de bron
Als een fervent GoTo hater mezelf, kan ik dat zeker waarderen en zal ik onderzoeken wat we aan de serverkant kunnen doen (de webservices zijn verbonden met een IBM Maximo-activabeheersysteem, dus ik kan beperkt zijn of misschien doet het dit al voor ons)
toegevoegd de auteur D.R., de bron