Webbtjänst (WS) Säkerhetshandledning med SOAP-exempel

Vad är WS Security?

WS Security är en standard som adresserar säkerhet när data utbyts som en del av en webbtjänst. Detta är en nyckelfunktion 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 ett säkerhetshot för webbapplikationer. När vi utvecklar webbaserade applikationer rekommenderas det därför alltid att se till att applikationen är utformad och utvecklad med säkerhet i åtanke.

I den här handledningen lär du dig-

• Säkerhetshot och motåtgärder
• Säkerhetsstandarder för webbtjänster
• Hur man bygger säkra webbtjänster
• Bästa praxis för webbtjänstsäkerhet

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 för en webbapplikation och se hur det fungerar när det gäller säkerhet.

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-lagret eller SSL för säker kommunikation. Både klienten och servern kommer att ha ett digitalt certifikat för att identifiera sig som äkta när någon 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 den här klienten.
2. Servern autentiserar sig sedan till klienten genom att skicka sitt 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å nödvändig data, skulle de inte kunna läsa den eftersom den skulle krypteras.

Men ovanstående typ av säkerhet fungerar inte i alla situationer. Det kan komma en tid då klienten kan prata med flera servrar. Ett exempel nedan visar en klient som pratar med både en databas och en webbserver åt gången. I sådana fall kan inte all information passera genom https-protokollet.

Det är här SOAP kommer i handling 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-huvudelementet.

Rubrikelementet 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 Body är krypterat skulle rubriken innehålla de nödvändiga krypteringsnycklarna så att meddelandet kan dekrypteras när det når målet.

I flera servermiljöer hjälper ovanstående teknik för SOAP-autentisering på följande sätt.

• Eftersom SOAP-kroppen är krypterad kan den bara dekrypteras av webbservern som är värd för webbtjänsten. Detta beror på hur SOAP-protokollet är utformat.
• Antag att om meddelandet skickas till databasservern i en HTTP-begäran, kan det 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 lämpligt svar tillbaka till klienten.

Vi kommer att se i de följande ämnena om hur WS-säkerhetsstandarden kan användas för SOAP.

Säkerhetsstandarder för webbtjänster

Som diskuterades i det tidigare avsnittet kretsar WS-säkerhetsstandarden om att säkerhetsdefinitionen ingår i SOAP Header.

Inloggningsuppgifterna i SOAP-rubriken hanteras på två sätt.

Först definierar det ett speciellt element som heter 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.

Nedanstående diagram visar flödet av hur säkerhetsmodellen fungerar i WS Security

Nedan följer stegen 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 speciellt konstruerad för att leverera användarnamn / lösenord eller certifikat till den faktiska SOAP-webbtjänsten.
2. Säkerhetstoken skickas sedan till webbtjänstklienten.
3. Webbtjänstklienten ringde sedan upp webbtjänsten, men den här gången säkerställde att säkerhetstoken är inbäddad i SOAP-meddelandet.
4. Webbtjänsten förstår sedan SOAP-meddelandet med autentiseringstoken och kan sedan kontakta tjänsten Security Token för att se om säkerhetstoken är giltig eller inte.

Nedanstående kodavsnitt visar formatet för autentiseringsdelen som ingår i WSDL-dokumentet. Baserat på nedanstående utdrag kommer SOAP-meddelandet att innehålla ytterligare två element, det ena är användarnamnet och det andra är lösenordet.

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 element med namnet definierat 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å SOAP-webbtjänstens säkerhetsexempel. Vi bygger en webbtjänstsäkerhet på exemplet som demonstrerades tidigare i SOAP-kapitlet och kommer att lägga till ett säkerhetslager i det.

I vårt exempel ska vi skapa en enkel webbtjänst som kommer att 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 åberopas, måste uppgifterna tillhandahållas 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 klickar du på menyalternativet Arkiv-> Nytt projekt.

När du klickar på alternativet Nytt projekt ger Visual Studio dig en annan dialogruta för att välja projekttyp 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 webbmallen C # för ASP.NET-webbapplikationen. Projektet måste vara av denna typ för att kunna skapa webbtjänstprojekt. Genom att välja detta alternativ kommer Visual Studio sedan att utföra nödvändiga steg för att lägga till nödvändiga filer som krävs av alla webbaserade applikationer.
2. Ge ett namn på ditt projekt som i vårt fall har fått som " webservice.asmx. " Se sedan till att ange en plats där projektfilerna kommer att lagras.

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

Steg 3) I detta steg,

Vi ska lägga till en webbtjänstfil i vårt projekt

1. Högerklicka först på projektfilen enligt nedan

2. När du högerklickar på projektfilen har du chansen att välja alternativet "Lägg till-> Webbtjänst (ASMX) för att lägga till en webbtjänstfil. Ange bara namnet Tutorial Service för webbtjänstens namnfil.

Ovanstående steg kommer att uppmana en dialogruta, där man kan ange namnet på webbtjänstfilen. Så i dialogrutan nedan anger du namnet på TutorialService som filnamn.

Steg 4) Lägg till följande kod i 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-rubriken när SOAP-meddelandet genereras. Eftersom vi nu vill lägga till säkerhetsinformation i SOAP-rubriken krävs detta steg.

return "This is a Guru99 Web Service";}public class AuthHeader : SoapHeader{public string UserName;public string Password;}}

Kodförklaring: -

1. Vi skapar nu en separat klass som heter AuthHeader som är av typen SoapHeader-klass . När du vill ändra vad som passeras i SOAP-rubriken måste du skapa en klass som använder den inbyggda SoapHeader-klassen i .Net. Genom att anpassa SOAPheader har vi nu möjlighet att skicka ett "användarnamn" och "lösenord" när webbtjänsten anropas.
2. Vi definierar sedan variabler för 'Användarnamn' och 'Lösenord' som är av typsträng. 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 i samma TutorialService.asmx-fil . Den här koden definierar faktiskt funktionen för vår webbtjänst. Den här funktionen returnerar strängen "Detta är en Guru99-webbtjänst" till klienten. Men den här gången kommer strängen endast att returneras om klientapplikationen skickar referenserna 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);}eisereturn "This is a Guru99 Web service";}

Kodfö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 Guru99Webservice där användarnamnet och lösenordet kan granskas noggrant.
2. Attributet [SoapHeader] används nu för att ange att när webbtjänsten anropas måste den ha passerat användarnamn och lösenord.
3. I detta kodblock undersöker vi faktiskt användarnamn och lösenord som skickats när webbtjänsten anropas. Om användarnamnet är lika med "Guru99" och lösenordet är lika med "Guru99Password" skickas meddelandet "This is a Guru99 Web service" till klienten. Annars skickas ett fel till klienten om fel användar-id och lösenord skickas.

Om koden körs framgångsrikt visas följande utdata 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å länken Service Description.

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

Bästa praxis för webbtjänstsäkerhet

Följande är de säkerhetsöverväganden som bör noteras när man arbetar med webbtjänster

1. Granskning och logghantering - Använd applikationsloggning för att logga alla förfrågningar som kommer till webbtjänsterna. Detta ger en detaljerad rapport om vem som har åberopat webbtjänsten och kan hjälpa till vid konsekvensanalys om säkerhetsintrång inträffar.

2. Flöde av samtal till webbtjänsten - Försök att notera samtalsflödet i webbtjänster. Som standard kan en applikation ringa flera webbtjänstförfrågningar med autentiseringstoken som skickas mellan dessa webbtjänster. Alla samtal mellan webbtjänster måste övervakas och loggas.

3. Känslig information - Ta inte med känslig information i dina loggposter som lösenord eller kreditkortsnummer eller någon annan typ av konfidentiell information. Om det finns en händelse som har någon av denna information, måste den kasseras innan du loggar in.

4. Spåra affärsverksamhet - Spåra betydande affärsverksamhet. Instrumentera till exempel din applikation för att registrera åtkomst till särskilt känsliga metoder och affärslogik. Låt oss ta ett exempel på en online shoppingapplikation. Det finns flera steg i en typisk applikation, till exempel att välja de artiklar som ska köpas, de artiklar som laddas i kundvagnen och sedan det slutliga köpet. Hela detta arbetsflöde måste spåras av webbtjänsten.

5. Korrekt autentisering - Autentisering är den mekanism genom vilken klienterna kan fastställa sin identitet med webbtjänsten med en viss uppsättning referenser som kan bevisa den identiteten. Man ska aldrig lagra användaruppgifterna, och om WS Security används för att ringa webbtjänsten måste det noteras att webbtjänsten inte ska lagra de autentiseringsuppgifter som skickas i SOAP-rubriken. Dessa bör kasseras av webbtjänsten.

Sammanfattning

• SOAP ger ett extra lager som kallas WS Security för att tillhandahålla ytterligare säkerhet när samtal görs till webbtjänster.
• WS Security kan anropas med ett enkelt användarnamn eller lösenord eller kan användas med binära certifikat för autentisering
• Vi har sett att vi i .Net kan anpassa webbtjänsten så att ett användarnamn och lösenord skickas som en del av SOAP-huvudelementet.