Web Service(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 mot webbapplikationer. Därför, när man utvecklar webbaserade applikationer, rekommenderas det alltid att se till att applikationen är designad 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 det fungerar när det gäller säkerhet.

En av säkerhetsåtgärderna som är tillgängliga för HTTP är HTTPS-protokollet. HTTPS är det säkra sättet för kommunikation mellan klienten och servern över webben. HTTPS använder sig av Secure Sockets-skiktet 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

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.
Servern autentiserar sig sedan för klienten genom att skicka dess certifikat. Detta säkerställer att klienten kommunicerar med rätt server.
All kommunikation därefter mellan klienten och servern är krypterad. Detta säkerställer att om några andra användare försöker bryta säkerheten och få den information som krävs, skulle de inte kunna läsa den eftersom den skulle vara krypterad.

Men ovanstående typ av säkerhet kommer inte att fungera 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 via https-protokollet.

Det är här SOAP kommer i aktion för att övervinna sådana hinder genom att ha WS Security-specifikationen på plats. Med denna specifikation definieras all säkerhetsrelaterade data i SOAP-huvudelementet.

Rubrikelementet kan innehålla nedanstående information

Om meddelandet i SOAP-kroppen har signerats med någon säkerhetsnyckel, kan den nyckeln definieras i rubrikelementet.
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 flera servermiljöer hjälper ovanstående teknik för SOAP-autentisering 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 om meddelandet skickas till databasservern i en HTTP-förfrågan, kan det inte dekrypteras eftersom databasen inte har rätt mekanismer för att göra det.
Först när förfrågan faktiskt når webbservern som ett SOAP-protokoll kommer den att kunna dechiffrera meddelandet och skicka rätt svar tillbaka till klienten.

Vi kommer att se i de efterföljande ämnena om hur WS Security-standarden kan användas för TVÅL.

Säkerhetsstandarder för webbtjänster

Som diskuterats i det tidigare avsnittet kretsar WS-Security-standarden kring att ha säkerhetsdefinitionen inkluderad i SOAP Header.

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

Först definierar den 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 av hur säkerhetsmodellen fungerar i WS Security

Nedan är stegen som sker i ovanstående arbetsflöde

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 byggd för att tillhandahålla användarnamn/lösenord eller certifikat till själva SOAP-webbtjänsten.
Säkerhetstoken skickas sedan till webbtjänstklienten.
Webbtjänstklienten anropade sedan webbtjänsten, men den här gången säkerställde att säkerhetstokenen är inbäddad i SOAP-meddelandet.
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 2 element, det ena är användarnamnet och det andra ä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 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änst säkerhetsexempel. Vi kommer att bygga en webbtjänstsäkerhet på exemplet som visades tidigare i SOAP-kapitlet och kommer att lägga till ett säkerhetslager till det.

I vårt exempel kommer vi att 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 anropas, måste inloggningsuppgifterna lämnas till den uppringande 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

Se till att du först väljer C# webbmall för ASP.NET webbapplikation. Projektet måste vara av denna typ för att skapa webbtjänstprojekt. Genom att välja detta alternativ kommer Visual Studio sedan att utföra de nödvändiga stegen för att lägga till nödvändiga filer som krävs av alla webbaserade applikationer.
Ge ditt projekt ett namn som i vårt fall har getts som "webservice.asmx.” Se sedan till att ange en plats där projektfilerna kommer att lagras.

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

Steg 3) I detta steg

Vi kommer att lägga till en webbtjänstfil till vårt projekt

Först Högerklicka på projektfilen som visas nedan

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 ett namn på Tutorial Service för webbtjänstens namnfil.

Ovanstående steg kommer att visa 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 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;

	}
}

Kodförklaring:-

Vi skapar nu en separat klass som heter AuthHeader som är av typ SoapHeader klass. När du vill ändra vad som skickas i SOAP-huvudet måste du skapa en klass som använder den inbyggda SoapHeader-klassen .Net. Genom att anpassa SOAPheadern har vi nu möjlighet att skicka ett "Användarnamn" och "Lösenord" när webbtjänsten anropas.
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-filen. Denna kod definierar faktiskt funktionen för vår webbtjänst. Denna funktion returnerar en sträng "Detta är en Guru99-webbtjänst" till klienten. Men den här gången kommer strängen bara att returneras om klientapplikationen skickar inloggningsuppgifterna 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);
		}
		eise
		return "This is a Guru99 Web service";
	}

Kodförklaring:-

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ändarnamn och lösenord kan granskas noggrant.
Attributet [SoapHeader] används nu för att specificera att när webbtjänsten anropas måste användarnamnet och lösenordet skickas.
I det här kodblocket undersöker vi faktiskt användarnamnet och lösenordet som skickas när webbtjänsten anropas. Om användarnamnet är lika med "Guru99" och lösenordet är lika med "Guru99Password" så skickas meddelandet "Detta är en Guru99-webbtjänst" till klienten. Annars kommer ett fel att skickas till klienten om fel användar-ID och lösenord skickas.

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 betyder 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äkerhetsöverväganden som bör noteras när du arbetar med webbtjänster

1. Revision 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 anlitat webbtjänsten och kan hjälpa till med Impactanalys om något 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 ett program anropa flera webbtjänsterbegäranden med autentiseringstokens som skickas mellan dessa webbtjänster. Alla samtal mellan webbtjänster behöver övervakas och loggas.

3. Känslig information – Inkludera inte känslig information i dina loggposter såsom lösenord eller kreditkortsnummer eller någon form av annan konfidentiell information. Om det finns en händelse som har någon av denna information måste den kasseras innan den loggas.

4. Spåra affärer Operationer – Spåra betydande affärsverksamheter. 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, som att välja de varor som ska köpas, de varor 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 kunderna kan fastställa sin identitet med webbtjänsten med hjälp av en viss uppsättning referenser 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 ska lagra inloggningsuppgifterna som skickas i SOAP-huvudet. Dessa ska kasseras av webbtjänsten.

Sammanfattning

SOAP tillhandahåller ett extra lager som kallas WS Security för att ge 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
Det har vi sett i . Net vi kan anpassa webbtjänsten så att ett användarnamn och lösenord skickas som en del av SOAP-huvudelementet.

Du kanske gillar: