Eksempel på webtjenestesikkerhed (WS) med SOAP
⚡ Smart opsummering
Web Service (WS) Security er en standard, der beskytter data, der udveksles under et SOAP-webservicekald. Denne ressource forklarer sikkerhedstrusler og modforanstaltninger, WS-sikkerhedsstandarder, opbygning af en sikker webtjeneste med legitimationsoplysninger og bedste praksis for webtjenestesikkerhed.
Hvad er WS Security?
WS Security er en standard, der håndterer sikkerhed, når data udveksles som en del af en webtjeneste. Dette er en nøglefunktion i SOAP, der gør den meget populær til oprettelse af webtjenester.
Sikkerhed er en vigtig funktion i enhver webapplikation. Da næsten alle webapplikationer er eksponeret for internettet, er der altid en risiko for en sikkerhedstrussel mod webapplikationer. Derfor, når der udviklesping webbaserede applikationer anbefales det altid at sikre, at applikationen er designet og udviklet med sikkerhed i tankerne.
Sikkerhedstrusler og modforanstaltninger
For at forstå sikkerhedstrusler, der kan være fjendtlige over for en webapplikation, lad os se på et simpelt scenarie for en webapplikation og se, hvordan den fungerer sikkerhedsmæssigt.
En af de sikkerhedsforanstaltninger, der er tilgængelige for HTTP, er HTTPS-protokollen. HTTPS er den sikre måde at kommunikere mellem klienten og serveren over internettet. HTTPS bruger Secure Sockets Layer, eller SSL, til sikker kommunikation. Både klienten og serveren har et digitalt certifikat til at identificere sig selv som ægte, når der sker kommunikation mellem klienten og serveren.
I en standard HTTPS-kommunikation mellem klienten og serveren finder følgende trin sted:
- Klienten sender en anmodning til serveren via klientcertifikatet. Når serveren ser klientcertifikatet, laver den en note i sit cachesystem, så den ved, at svaret kun skal gå tilbage til denne klient.
- Serveren autentificerer sig selv over for klienten ved at sende dens certifikat. Dette sikrer, at klienten kommunikerer med den rigtige server.
- Al kommunikation derefter mellem klienten og serveren er krypteret. Dette sikrer, at hvis andre brugere forsøger at bryde sikkerheden og få fat i de nødvendige data, vil de ikke være i stand til at læse dem, fordi de vil være krypterede.
Men ovenstående type sikkerhed vil ikke fungere i alle situationer. Der kan komme et tidspunkt, hvor klienten kan kommunikere med flere servere. Et eksempel nedenfor viser en klient, der kommunikerer med både en database og en webserver ad gangen. I sådanne tilfælde kan ikke al information passere gennem HTTPS-protokollen.
Det er her, SOAP kommer i spil for at overvinde sådanne hindringer ved at have WS Security-specifikationen på plads. Med denne specifikation defineres alle sikkerhedsrelaterede data i SOAP header-elementet. Header-elementet kan indeholde nedenstående oplysninger:
- Hvis meddelelsen i SOAP-legemet er blevet signeret med en sikkerhedsnøgle, kan denne nøgle defineres i header-elementet.
- Hvis et element i SOAP-brødteksten er krypteret, vil headeren indeholde de nødvendige krypteringsnøgler, så beskeden kan dekrypteres, når den når destinationen.
I et miljø med flere servere hjælper ovenstående teknik til SOAP-godkendelse på følgende måde:
- Da SOAP-kroppen er krypteret, vil den kun kunne dekrypteres af den webserver, der er vært for webtjenesten. Dette er på grund af, hvordan SOAP-protokollen er designet.
- Antag, at beskeden sendes til databaseserveren i en HTTP-anmodning; den kan ikke dekrypteres, fordi databasen ikke har de rette mekanismer til at gøre det.
- Først når anmodningen rent faktisk når webserveren som en SOAP-protokol, vil den være i stand til at dechifrere beskeden og sende det relevante svar tilbage til klienten.
I de efterfølgende emner vil vi se på, hvordan WS Security-standarden kan bruges til SOAP.
Web Service Sikkerhedsstandarder
Som omtalt i det tidligere afsnit, drejer WS-Security-standarden sig om at have sikkerhedsdefinitionen inkluderet i SOAP-headeren. Legitimationsoplysningerne i SOAP-headeren administreres på to måder.
Først defineres et særligt element kaldet UsernameToken. Dette bruges til at videregive brugernavn og adgangskode til webtjenesten. Den anden måde er at bruge et binært token via BinarySecurityToken. Dette bruges i situationer, hvor krypteringsteknikker som Kerberos eller X.509 anvendes.
Diagrammet nedenfor viser, hvordan sikkerhedsmodellen fungerer i WS Security.
Nedenfor er de trin, der finder sted i ovenstående arbejdsgang:
- En anmodning kan sendes fra webtjenesteklienten til Security Token Service. Denne tjeneste kan være en mellemliggende webtjeneste, der er specifikt bygget til at levere brugernavne/adgangskoder eller certifikater til den faktiske SOAP-webtjeneste.
- Sikkerhedstokenet videregives derefter til webserviceklienten.
- Webtjenesteklienten kalder derefter webtjenesten, men denne gang sikrer den, at sikkerhedstokenet er integreret i SOAP-meddelelsen.
- Webtjenesten forstår derefter SOAP-meddelelsen med godkendelsestokenet og kan derefter kontakte Security Token-tjenesten for at se, om sikkerhedstokenet er autentisk eller ej.
Nedenstående kodestykke viser formatet for godkendelsesdelen, som er en del af WSDL-dokumentet. Baseret på nedenstående kodestykke vil SOAP-meddelelsen indeholde to yderligere elementer, hvoraf det ene er brugernavnet og det andet er adgangskoden.
<xs:element name="UsernameToken"> <xs:complexType> <xs:sequence> <xs:element ref="Username"/> <xs:element ref="Password" minOccurs="0"/> </xs:sequence> <xs:attribute name="Id" type="xs:ID"/> </xs:complexType> </xs:element>
Når SOAP-meddelelsen faktisk sendes mellem klienterne og serveren, kan den del af meddelelsen, der indeholder brugerlegitimationsoplysningerne, se ud som den ovenfor viste. wsse-elementnavnet er et særligt elementnavn defineret til SOAP og betyder, at det indeholder sikkerhedsbaserede oplysninger.
Sådan bygger du sikre webtjenester
Lad os nu se på et eksempel på en SOAP-webtjenestesikkerhed. Vi vil bygge en webtjenestesikkerhed på det eksempel, der blev demonstreret tidligere i SOAP-kapitlet, og tilføje et sikkerhedslag til det.
I vores eksempel skal vi oprette en simpel webtjeneste, som skal bruges til at returnere en streng til den applikation, der kalder webtjenesten. Men denne gang, når webtjenesten kaldes, skal legitimationsoplysningerne angives til den kaldende tjeneste. Lad os følge nedenstående trin for at oprette vores SOAP-webtjeneste og tilføje sikkerhedsdefinitionen til den.
Trin 1) Det første trin er at oprette en tom Asp.Net Webapplikation. Fra Visual Studio 2013 skal du klikke på menupunktet Filer->Nyt projekt.
Når du klikker på indstillingen Nyt projekt, giver Visual Studio dig en anden dialogboks til at vælge projekttype og give de nødvendige detaljer om projektet. Dette forklares i næste trin.
Trin 2) I dette trin,
- Sørg for, at du først vælger C# Webskabelon til ASP.NET-webapplikation. Projektet skal være af denne type for at kunne oprette et webserviceprojekt. Ved at vælge denne indstilling vil Visual Studio derefter udføre de nødvendige trin for at tilføje nødvendige filer, som enhver webbaseret applikation har brug for.
- Giv dit projekt et navn, som i vores tilfælde er blevet givet som "webservice.asmx". Sørg derefter for at angive en placering, hvor projektfilerne skal gemmes.
Når det er gjort, vil du se den projektfil, der er oprettet i din løsningsbrowser i Visual Studio 2013.
Trin 3) I dette trin vil vi tilføje en webservicefil til vores projekt.
- Højreklik først på projektfilen som vist nedenfor.
- Når du højreklikker på projektfilen, har du mulighed for at vælge indstillingen "Tilføj->Webtjeneste (ASMX)" for at tilføje en webtjenestefil. Angiv blot navnet på Tutorial Service til webtjenestenavnfilen.
Ovenstående trin vil åbne en dialogboks, hvor man kan indtaste navnet på webservicefilen. Indtast derfor navnet på TutorialService som filnavn i dialogboksen nedenfor.
Trin 4) Tilføj følgende kode til din Tutorial Service asmx-fil. Nedenstående kodestykke bruges til at tilføje en brugerdefineret klasse, som vil blive brugt til at ændre SOAP-headeren, når SOAP-meddelelsen genereres. Da vi nu ønsker at tilføje sikkerhedsoplysninger til SOAP-headeren, er dette trin påkrævet.
return "This is a Guru99 Web Service"; } public class AuthHeader : SoapHeader { public string UserName; public string Password; } }
Code Forklaring:
- Vi er nu ved at oprette en separat klasse kaldet AuthHeader som er af typen SoapHeader klasseNår man vil ændre, hvad der sendes i SOAP-headeren, skal man oprette en klasse, der bruger den indbyggede SoapHeader-klasse fra .Net. Ved at tilpasse SOAP-headeren har vi nu mulighed for at sende et 'Brugernavn' og en 'Adgangskode', når webtjenesten kaldes.
- Vi definerer derefter variabler af 'Brugernavn' og 'Password', som er af typen streng. De vil blive brugt til at indeholde værdierne af brugernavnet og adgangskoden, som videregives til webtjenesten.
Trin 5) Som det næste trin skal følgende kode tilføjes til det samme TutorialService.asmx filDenne kode definerer faktisk funktionen af vores webservice. Funktionen returnerer en streng "Dette er en Guru99 Webtjeneste” til klienten. Men denne gang returneres strengen kun, hvis klientapplikationen sender legitimationsoplysningerne til webtjenesten.
public class TutorialService : System.Web.Services.WebService { public AuthHeader Credentials; [SoapHeader("Credentials")] [WebMethod] public string Guru99WebService() { if (Credentials.UserName.ToLower() != "Guru99" || Credentials.Password.ToLower() != "Guru99Password") { throw new SoapException("Unauthorized", SoapException.ClientFaultCode); } else return "This is a Guru99 Web service"; }
Code Forklaring:
- Her opretter vi et objekt af AuthHeader-klassen, som blev oprettet i det tidligere trin. Dette objekt vil blive videregivet til vores Guru99Webservice hvor brugernavn og adgangskode kan undersøges nærmere.
- [SoapHeader]-attributten bruges nu til at angive, at når webtjenesten kaldes, skal brugernavnet og adgangskoden sendes.
- I denne kodeblok undersøger vi faktisk brugernavnet og adgangskoden, der angives, når webtjenesten kaldes. Hvis brugernavnet er lig med "Guru99” og adgangskoden er lig med “Guru99Password”, derefter meddelelsen “Dette er en Guru99 Webtjeneste” sendes til klienten. Ellers sendes der en fejl til klienten, hvis der angives forkert bruger-id og adgangskode.
Hvis koden eksekveres med succes, vil følgende output blive vist, når du kører din kode i browseren.
Output:
Ovenstående output vises, når programmet køres, hvilket betyder, at webtjenesten nu er tilgængelig. Lad os klikke på Tjenesten Descriptionforbindelse.
Fra tjenestebeskrivelsen vil du nu kunne se, at brugernavnet og adgangskoden er elementer i wsdl fil. Disse parametre skal sendes, når webtjenesten aktiveres.
Web Service Security Bedste Practices
Følgende er de sikkerhedsmæssige overvejelser, der skal være opmærksomme på, når man arbejder med webtjenester:
- Revision og loghåndtering – Brug programlogning til at logge alle anmodninger, der kommer til webtjenesterne. Dette giver en detaljeret rapport om, hvem der har kaldt webtjenesten, og kan hjælpe med konsekvensanalyse, hvis der opstår et sikkerhedsbrud.
- Opkaldsflow til webtjenesten – Prøv at notere flowet af kald i webtjenester. Som standard kan en applikation kalde flere webtjenesteanmodninger med godkendelsestokens sendt mellem disse webtjenester. Alle kald mellem webtjenester skal overvåges og logges.
- Følsomme oplysninger – Medtag ikke følsomme oplysninger i dine logposter, såsom adgangskoder, kreditkortnumre eller andre fortrolige oplysninger. Hvis der er en hændelse, der indeholder disse oplysninger, skal den kasseres, før logføring.
- Track Forretning Operationer - Track væsentlige forretningsaktiviteter. For eksempel, instrumentér din applikation til at registrere adgang til særligt følsomme metoder og forretningslogik. Tag et eksempel på en onlinebutikping applikation. Der er flere trin i en typisk applikation, såsom at vælge de varer, der skal købes, de varer, der lægges i kurven, og derefter det endelige køb. Hele denne forretningsworkflow skal være tracbedt af webtjenesten.
- Korrekt godkendelse – Godkendelse er den mekanisme, hvormed klienter kan etablere deres identitet med webtjenesten ved hjælp af et bestemt sæt legitimationsoplysninger, der kan bevise denne identitet. Man bør aldrig gemme brugerlegitimationsoplysningerne, og derfor skal det bemærkes, at webtjenesten ikke bør gemme de legitimationsoplysninger, der sendes i SOAP-headeren, hvis WS Security bruges til at kalde webtjenesten. Disse bør kasseres af webtjenesten.














