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.

  • 🔐 Kernestandard: WS-Security tilføjer et sikkerhedslag til SOAP, der definerer, hvordan legitimationsoplysninger og krypteringsnøgler bevæger sig inde i SOAP-headeren.
  • 🌐 HTTPS-grænser: HTTPS/SSL sikrer punkt-til-punkt-trafik, men i multi-server-flows er det kun WS-Security, der beskytter meddelelsen fra ende til anden.
  • 🎫 Legitimationstokens: Legitimationsoplysninger videregives ved hjælp af et UsernameToken til brugernavn og adgangskode eller et BinarySecurityToken til Kerberos- eller X.509-certifikater.
  • 🛠️ Eksempel på sikker bygning: En .Net ASMX-webtjeneste tilføjer en AuthHeader-klasse, så SOAP-headeren indeholder et brugernavn og en adgangskode til godkendelse.
  • ???? Bedste praksis: Revisions- og logforespørgsler, track forretningsdrift, autentificer korrekt og opbevar eller logfør aldrig følsomme legitimationsoplysninger.

Webtjeneste WS-sikkerhed

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.

Sikkerhedstrusler og modforanstaltninger HTTPS

I en standard HTTPS-kommunikation mellem klienten og serveren finder følgende trin sted:

  1. 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.
  2. Serveren autentificerer sig selv over for klienten ved at sende dens certifikat. Dette sikrer, at klienten kommunikerer med den rigtige server.
  3. 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.

Sikkerhedstrusler og modforanstaltninger mod flere servere

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:

  1. Hvis meddelelsen i SOAP-legemet er blevet signeret med en sikkerhedsnøgle, kan denne nøgle defineres i header-elementet.
  2. 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.

Arbejdsgang for webtjenesters sikkerhedsstandarder

Nedenfor er de trin, der finder sted i ovenstående arbejdsgang:

  1. 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.
  2. Sikkerhedstokenet videregives derefter til webserviceklienten.
  3. Webtjenesteklienten kalder derefter webtjenesten, men denne gang sikrer den, at sikkerhedstokenet er integreret i SOAP-meddelelsen.
  4. 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.

Byg et nyt projekt med sikre webtjenester

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,

  1. 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.
  2. 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.

Detaljer om projektet "Build Secure Web Services"

Når det er gjort, vil du se den projektfil, der er oprettet i din løsningsbrowser i Visual Studio 2013.

Opbyg Secure Web Services-løsningsudforsker

Trin 3) I dette trin vil vi tilføje en webservicefil til vores projekt.

  1. Højreklik først på projektfilen som vist nedenfor.

Højreklik på projektet "Byg sikre webtjenester"

  1. 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.

Byg sikre webtjenester tilføj webtjeneste

Ovenstående trin vil åbne en dialogboks, hvor man kan indtaste navnet på webservicefilen. Indtast derfor navnet på TutorialService som filnavn i dialogboksen nedenfor.

Dialogboksen Navn på Byg sikre webtjenester

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.

Byg AuthHeader-kode til sikre webtjenester

      return "This is a Guru99 Web Service";
   }

   public class AuthHeader : SoapHeader
   {
      public string UserName;
      public string Password;
   }
}

Code Forklaring:

  1. 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.
  2. 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.

Byg sikre webtjenester - selvstudier Servicekode

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:

  1. 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.
  2. [SoapHeader]-attributten bruges nu til at angive, at når webtjenesten kaldes, skal brugernavnet og adgangskoden sendes.
  3. 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:

Output fra Byg Secure Web Services

Ovenstående output vises, når programmet køres, hvilket betyder, at webtjenesten nu er tilgængelig. Lad os klikke på Tjenesten Descriptionforbindelse.

Beskrivelse af tjenesten Build Secure Web Services

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Ofte Stillede Spørgsmål

AI kan overvåge webtjenestetrafik i realtid, registrere usædvanlige anmodningsmønstre og markere sandsynlige angreb såsom injektion eller tokenmisbrug. Den kan også scanne WSDL- og SOAP-konfigurationer for svag godkendelse eller manglende kryptering.

Ja. Maskinlæringsmodeller, der er trænet på normal trafik, kan opdage uregelmæssigheder som f.eks. udfyldning af legitimationsoplysninger, misdannede SOAP-headere eller replay-angreb. Sikkerhedsteams bør stadig gennemgå advarsler, før de blokerer anmodninger, for at undgå at forstyrre legitime klienter.

HTTPS krypterer forbindelsen mellem to punkter, så data eksponeres, når de når en mellemliggende server. WS-Security sikrer selve SOAP-meddelelsen.ping den beskytter fra ende til anden, selv når den passerer gennem flere servere.

Et UsernameToken er et WS-Security-element placeret i SOAP-headeren, der indeholder et brugernavn og eventuelt en adgangskode. Det giver en webtjeneste mulighed for at godkende den, der ringer op, før anmodningen behandles.

Opsummer dette indlæg med: