Webbtjänstsäkerhet (WS) med SOAP-exempel

Vad är WS Security?

WS Security är en standard som hanterar säkerhet när data utbyts som en del av en webbtjänst. Detta är en viktig funktion i SOAP som gör den mycket populär för att skapa webbtjänster.

Säkerhet är en viktig funktion i alla webbapplikationer. Eftersom nästan alla webbapplikationer är exponerade för internet finns det alltid en risk för säkerhetshot mot webbapplikationer. Därför, när utvecklingping webbaserade applikationer rekommenderas det alltid att se till att applikationen är utformad och utvecklad med säkerhet i åtanke.

Säkerhetshot och motåtgärder

För att förstå säkerhetshot som kan vara fientliga mot en webbapplikation, låt oss titta på ett enkelt scenario av en webbapplikation och se hur den fungerar säkerhetsmässigt.

En av de säkerhetsåtgärder som finns tillgängliga för HTTP är HTTPS-protokollet. HTTPS är det säkra sättet att kommunicera mellan klienten och servern via webben. HTTPS använder Secure Sockets Layer, eller SSL, för säker kommunikation. Både klienten och servern har ett digitalt certifikat för att identifiera sig som äkta när kommunikation sker mellan klienten och servern.

I en vanlig HTTPS-kommunikation mellan klienten och servern sker följande steg:

1. Klienten skickar en begäran till servern via klientcertifikatet. När servern ser klientcertifikatet gör den en anteckning i sitt cachesystem så att den vet att svaret bara ska gå tillbaka till denna klient.
2. Servern autentiserar sig sedan för klienten genom att skicka dess certifikat. Detta säkerställer att klienten kommunicerar med rätt server.
3. All kommunikation därefter mellan klienten och servern är krypterad. Detta säkerställer att om andra användare försöker bryta säkerheten och få tag på nödvändig information, kommer de inte att kunna läsa den eftersom den är krypterad.

Men ovanstående typ av säkerhet fungerar inte i alla situationer. Det kan komma en tidpunkt då klienten kan kommunicera med flera servrar. Ett exempel nedan visar en klient som kommunicerar med både en databas och en webbserver samtidigt. I sådana fall kan inte all information passera genom HTTPS-protokollet.

Det är här SOAP kommer in i bilden för att övervinna sådana hinder genom att ha WS Security-specifikationen på plats. Med denna specifikation definieras all säkerhetsrelaterad data i SOAP-headerelementet. Headerelementet kan innehålla informationen nedan:

1. Om meddelandet i SOAP-kroppen har signerats med någon säkerhetsnyckel, kan den nyckeln definieras i rubrikelementet.
2. Om något element i SOAP-kroppen är krypterat, skulle rubriken innehålla de nödvändiga krypteringsnycklarna så att meddelandet kan dekrypteras när det når destinationen.

I en miljö med flera servrar hjälper ovanstående teknik för SOAP-autentisering till på följande sätt:

• Eftersom SOAP-kroppen är krypterad kommer den bara att kunna dekrypteras av webbservern som är värd för webbtjänsten. Detta beror på hur SOAP-protokollet är utformat.
• Anta att meddelandet skickas till databasservern i en HTTP-förfrågan; det kan inte dekrypteras eftersom databasen inte har rätt mekanismer för att göra det.
• Först när begäran faktiskt når webbservern som ett SOAP-protokoll kommer den att kunna dechiffrera meddelandet och skicka tillbaka lämpligt svar till klienten.

I följande avsnitt kommer vi att se hur WS Security-standarden kan användas för TVÅL.

Säkerhetsstandarder för webbtjänster

Som diskuterats i tidigare avsnitt kretsar WS-Security-standarden kring att säkerhetsdefinitionen ska inkluderas i SOAP-headern. Inloggningsuppgifterna i SOAP-headern hanteras på två sätt.

Först definieras ett speciellt element som kallas UsernameToken. Detta används för att skicka användarnamn och lösenord till webbtjänsten. Det andra sättet är att använda en binär token via BinarySecurityToken. Detta används i situationer där krypteringstekniker som Kerberos eller X.509 används.

Diagrammet nedan visar flödet för hur säkerhetsmodellen fungerar i WS Security.

Nedan följer stegen som sker i ovanstående arbetsflöde:

1. En begäran kan skickas från webbtjänstklienten till Security Token Service. Denna tjänst kan vara en mellanliggande webbtjänst som är specifikt byggd för att tillhandahålla användarnamn/lösenord eller certifikat till själva SOAP-webbtjänsten.
2. Säkerhetstoken skickas sedan till webbtjänstklienten.
3. Webbtjänstklienten anropar sedan webbtjänsten, men den här gången säkerställer den att säkerhetstoken är inbäddad i SOAP-meddelandet.
4. Webbtjänsten förstår sedan SOAP-meddelandet med autentiseringstoken och kan sedan kontakta Security Token-tjänsten för att se om säkerhetstoken är autentisk eller inte.

Nedanstående utdrag visar formatet för autentiseringsdelen som är en del av WSDL-dokumentet. Baserat på utdraget nedan kommer SOAP-meddelandet att innehålla ytterligare två element, ett som är användarnamnet och det andra som är lösenordet.

<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-meddelandet faktiskt skickas mellan klienterna och servern kan den del av meddelandet som innehåller användaruppgifterna se ut som den som visas ovan. wsse-elementnamnet är ett speciellt elementnamn som definieras för SOAP och betyder att det innehåller säkerhetsbaserad information.

Hur man bygger säkra webbtjänster

Låt oss nu titta på ett exempel på säkerhet för webbtjänster i SOAP. Vi kommer att bygga en webbtjänstsäkerhet utifrån exemplet som demonstrerades tidigare i SOAP-kapitlet och lägga till ett säkerhetslager till det.

I vårt exempel ska vi skapa en enkel webbtjänst som ska användas för att returnera en sträng till applikationen som anropar webbtjänsten. Men den här gången, när webbtjänsten anropas, måste autentiseringsuppgifterna anges till den anropande tjänsten. Låt oss följa stegen nedan för att skapa vår SOAP-webbtjänst och lägga till säkerhetsdefinitionen till den.

Steg 1) Det första steget är att skapa en tom Asp.Net Webbapplikation. Från Visual Studio 2013, klicka på menyalternativet Arkiv->Nytt projekt.

När du klickar på alternativet Nytt projekt kommer Visual Studio att ge dig en annan dialogruta för att välja typ av projekt och för att ge nödvändiga detaljer om projektet. Detta förklaras i nästa steg.

Steg 2) I detta steg

1. Se till att du först väljer C# webbmall för ASP.NET-webbapplikation. Projektet måste vara av den här typen för att skapa ett webbtjänstprojekt. Genom att välja det här alternativet kommer Visual Studio sedan att utföra de nödvändiga stegen för att lägga till nödvändiga filer som behövs av alla webbaserade applikationer.
2. Ge ditt projekt ett namn som i vårt fall har getts som "webbtjänst.asmx"Se sedan till att ange en plats där projektfilerna ska lagras.

När det är klart ser du projektfilen som skapats i din lösningsutforskare i Visual Studio 2013.

Steg 3) I det här steget ska vi lägga till en webbtjänstfil i vårt projekt.

1. Högerklicka först på projektfilen som visas nedan.

2. När du högerklickar på projektfilen har du möjlighet att välja alternativet "Lägg till->Webbtjänst (ASMX)" för att lägga till en webbtjänstfil. Ange bara namnet på Handledningstjänsten för webbtjänstnamnfilen.

Ovanstående steg öppnar en dialogruta där man kan ange namnet på webbtjänstfilen. I dialogrutan nedan anger du namnet på TutorialService som filnamn.

Steg 4) Lägg till följande kod till din Tutorial Service asmx-fil. Nedanstående kodavsnitt används för att lägga till en anpassad klass som kommer att användas för att ändra SOAP Header när SOAP-meddelandet genereras. Eftersom vi nu vill lägga till säkerhetsuppgifter till SOAP-huvudet är detta steg obligatoriskt.

      return "This is a Guru99 Web Service";
   }

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

Code Förklaring:

1. Vi skapar nu en separat klass som heter AuthHeader som är av typ SoapHeader klassNär man vill ändra vad som skickas i SOAP-headern måste man skapa en klass som använder den inbyggda SoapHeader-klassen i .Net. Genom att anpassa SOAP-headern har vi nu möjlighet att skicka ett "Användarnamn" och ett "Lösenord" när webbtjänsten anropas.
2. Vi definierar sedan variabler för 'UserName' och 'Password' som är av typen string. De kommer att användas för att hålla värdena för användarnamnet och lösenordet som skickas till webbtjänsten.

Steg 5) Som nästa steg måste följande kod läggas till densamma TutorialService.asmx-filenDen här koden definierar faktiskt funktionen för vår webbtjänst. Funktionen returnerar strängen "Detta är en Guru99 Webbtjänst” till klienten. Men den här gången returneras strängen bara om klientapplikationen skickar autentiseringsuppgifterna till webbtjänsten.

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 Förklaring:

1. Här skapar vi ett objekt av klassen AuthHeader som skapades i det tidigare steget. Detta objekt kommer att skickas till vår Guru99Webtjänst där användarnamn och lösenord kan granskas noggrant.
2. Attributet [SoapHeader] används nu för att specificera att när webbtjänsten anropas måste användarnamnet och lösenordet skickas.
3. I det här kodblocket undersöker vi faktiskt användarnamnet och lösenordet som anges när webbtjänsten anropas. Om användarnamnet är lika med "Guru99” och lösenordet är lika med “Guru99Password”, sedan meddelandet “Detta är ett Guru99 Webbtjänst” skickas till klienten. Annars skickas ett felmeddelande till klienten om fel användar-ID och lösenord anges.

Om koden exekveras framgångsrikt kommer följande utdata att visas när du kör din kod i webbläsaren.

Produktion:

Ovanstående utdata visas när programmet körs, vilket innebär att webbtjänsten nu är tillgänglig. Låt oss klicka på Tjänsten Descriptjonlänk.

Från tjänstebeskrivningen kommer du nu att kunna se att användarnamnet och lösenordet är delar av wsdl fil. Dessa parametrar måste skickas när webbtjänsten anropas.

Best Practices för webbtjänstsäkerhet

Följande är säkerhetsaspekter som bör beaktas när man arbetar med webbtjänster:

1. Revision och logghantering – Använd programloggning för att logga alla förfrågningar som kommer till webbtjänsterna. Detta ger en detaljerad rapport om vem som har anropat webbtjänsten och kan hjälpa till vid konsekvensanalyser om ett säkerhetsintrång inträffar.
2. Flödet av samtal till webbtjänsten – Försök att notera flödet av anrop i webbtjänster. Som standard kan en applikation anropa flera webbtjänstförfrågningar med autentiseringstokens som skickas mellan dessa webbtjänster. Alla anrop mellan webbtjänster måste övervakas och loggas.
3. Känslig information – Inkludera inte känslig information i dina loggposter, såsom lösenord, kreditkortsnummer eller annan konfidentiell information. Om det finns en händelse som innehåller någon av dessa uppgifter måste den kasseras innan loggning.
4. Track Företag Operationer - Track betydande affärsverksamheter. Till exempel, instrumentera din applikation för att registrera åtkomst till särskilt känsliga metoder och affärslogik. Ta ett exempel på en webbutikping applikation. Det finns flera steg i en typisk applikation, som att välja de varor som ska köpas, de varor som ska läggas i varukorgen och sedan det slutliga köpet. Hela detta affärsarbetsflöde måste trachämtad av webbtjänsten.
5. Korrekt autentisering – Autentisering är den mekanism genom vilken klienter kan fastställa sin identitet med webbtjänsten med hjälp av en viss uppsättning autentiseringsuppgifter som kan bevisa den identiteten. Man bör aldrig lagra användaruppgifterna, och därför, om WS Security används för att anropa webbtjänsten, måste det noteras att webbtjänsten inte bör lagra de autentiseringsuppgifter som skickas i SOAP-headern. Dessa bör kasseras av webbtjänsten.

Vanliga frågor