Suche
Verteidigungsstrategien moderner Webanwendungen

Sicher in die Cloud mit Angular und Spring

Andreas Falk

©Shutterstock/cybrain

Single-Page-Anwendungen auf Basis von Angular in Kombination mit Spring Boot Microservices sind aktuell sehr beliebt. Im Zeitalter der Cloud und mithilfe von Praktiken wie Continuous Delivery sind sie auch schnell in Produktion gebracht. Doch wie steht es um die Sicherheit derartiger Anwendungen?

In den letzten Jahren hat sich die Sicherheit vieler Webanwendungen spürbar verbessert. Das ist einerseits auf ein erhöhtes Sicherheitsbewusstsein in der Entwicklung zurückzuführen, andererseits tragen Bewegungen wie DevOpsSec [1] und die fortschreitende Integration der Sicherheit in agile Entwicklungsprozesse ebenfalls entscheidend dazu bei. Inzwischen machen es viele Frameworks durch ihre „Secure by Default“-Implementierung den Entwicklern auch wesentlich leichter, Anwendungen sicher umzusetzen. Zwei prominente Vertreter dieser Art werde ich in diesem Artikel genauer vorstellen: Zum einen Angular für die Entwicklung von Webclients , zum anderen die Spring-Plattform als Basis für die Implementierung der Serverseite. In einem Projekt im IoT-Cloud-Umfeld sammle ich aktuell entsprechende Erfahrungen.

Abbildung 1 zeigt die dem Projekt zugrunde liegende Architektur mit Angular Frontend, API-Gateway, Service-Discovery-Dienst sowie mehrere mit Spring Boot implementierte Microservices. Das Konzept des API-Gateways mit Service Discovery wird in [2] im Detail vorgestellt. Hinsichtlich der Sicherheit wird dort meist HTTPS terminiert und z. B. ein Authentifizierungstoken validiert. Schließlich ist auch noch der .NET-basierte IdentityServer3 als OpenID Connect Identity Provider mit involviert.

Abb. 1: Spring-Boot-Microservices-Architektur mit Angular Frontend und IdentityServer3

Abb. 1: Spring-Boot-Microservices-Architektur mit Angular Frontend und IdentityServer3

Die Microservices im Projekt sind wie in Abbildung 2 aufgebaut. Das RESTful API mit Hypermedia-Elementen ist mit Spring MVC und Spring HATEOAS implementiert. Für die sichere Bereitstellung kommt Spring Security inklusive dem Spring-Security-OAuth-Modul zum Einsatz. Zur Datenhaltung wird eine relationale Datenbank verwendet, auf die mittels Spring Data JPA plus Hibernate als Provider zugegriffen wird. Aus dem Spring-Cloud-Projekt werden hier neben dem Netflix-Stack noch der Cloud Config Server und die Cloud Connectors verwendet. Spring Boot ermöglicht es durch seine Autokonfiguration, einen Microservice mit den erwähnten Spring-Modulen einfach aufzusetzen. Die Anwendungsteile werden alle in einer von Kundenseite als Private Cloud aufgesetzten Cloud-Foundry-Instanz betrieben.

Abb. 2: Spring-Module innerhalb der Microservices

Abb. 2: Spring-Module innerhalb der Microservices

Angular mit Schutz vor XSS- und CSRF-Angriffen

Seit September letzten Jahres ist das finale Release von Angular verfügbar. Dennoch hat auch Angular 1 nochmals die Aufmerksamkeit auf sich gezogen, als die Expression Sandbox in Release 1.6 entfernt wurde. Die Expression Sandbox hatte in der Vergangenheit für viele Missverständnisse gesorgt, da viele Entwickler irrtümlich davon ausgegangen waren, die Sandbox würde die Anwendung vor allen Sicherheitsproblemen schützen. Das hat sich aber gerade im Hinblick auf die häufig eingebauten Template Injections als fatal erwiesen. Template Injections werden durch das serverseitige Generieren der Angular-Templates ermöglicht, z. B. durch die Kombination von Angular mit Spring MVC und Thymeleaf. Wird hier beim Laden der dynamischen HTML-Seite direkt ein Query-Parameter ungeprüft übernommen, lassen sich beliebige Angular-Ausdrücke direkt zur Ausführung injizieren.

In Angular hat man aus diesem Grund bereits während der Neuentwicklung stark darauf geachtet, das Framework analog zur Version 1 standardmäßig mit entsprechenden Sicherheitsmechanismen auszustatten. Auf eine Expression Sandbox wurde aus den genannten Gründen gleich von vornherein verzichtet. Angular bietet einen, im Gegensatz zu Angular 1 auch entsprechend gut dokumentierten, umfassenden Schutz vor Cross-Site Scripting (XSS). Dies wird durch automatisches Encoding und eine kontextabhängige Säuberung (engl.: Sanitizing) aller mit Angular gebundenen Ausgaben in den Templates bewerkstelligt. Das Sanitizing findet dabei in folgenden Kontexten statt: HTML, CSS-Stilangaben, URLs (z. B. in Links) und Ressourcen-URLs (z. B. in iFrames).

Lesen Sie auch: Spring 5 ist da! Frühling für Enterprise Java

In Listing 1 wird eine in TypeScript implementierte Angular-2-Komponente dargestellt, die im Attribut untrusted einen potenziell gefährlichen JavaScript-Anteil enthält. In Listing 2 wird der Wert dieses Attributs je einmal gebunden als Text ({{untrusted}}) und als HTML ([innerHtml]=“untrusted“) im Angular-Template ausgegeben. Wie in Abbildung 2 zu sehen ist, werden die HTML- und JavaScript-Anteile im ersten Fall von Angular durch ungefährliche HTML-Entities ersetzt. Im zweiten Fall soll der Wert nun tatsächlich als HTML interpretiert ausgegeben werden. Daher ist hier keine Encodierung wie im ersten Fall möglich. Durch das Sanitizing werden stattdessen von Angular nur HTML-Elemente durchgelassen (Whitelisting) und entsprechend unerwünschte Elemente (z. B. <script>) einfach ignoriert. Das wird dem Entwickler im Angular-Entwicklungsmodus auch durch entsprechende Logausgaben mitgeteilt.

import {Component} from '@angular/core';
@Component({
  selector: 'app-root',
  templateUrl: 'app.component.html'
})
export class AppComponent {
  untrusted:string = '<b><script>alert("Hallo XSS!")</script></b>';
}
Als Text:
<div>{{untrusted}}</div>
Als HTML:
<div [innerHtml]="untrusted"></div>
Abb. 3: Sicher entschärfte Anzeige des Inhalts im Browser

Abb. 3: Sicher entschärfte Anzeige des Inhalts im Browser

Allerdings bietet Angular auch entsprechende API-Methoden (u. a. bypassSecurityTrustHtml) an, mit denen man diese Sicherheitsmechanismen explizit deaktivieren kann. Hier sollte man genau prüfen, welche Werte verarbeitet werden. Diese gefährlichen APIs sind vorbildlich in der Dokumentation unübersehbar als Sicherheitsrisiko markiert. Auch Template Injections sind mit Angular weiter möglich. Allerdings gibt es hier mit dem Offline Template Compiler eine wirkungsvolle Verteidigung, falls unbedingt serverseitig generierte Templates benötigt werden.

Neben den gerade vorgestellten XSS-Schutzmechanismen lässt sich in Angular auch der standardmäßig implementierte Schutz als Double Submit Cookie gegen Cross-Site-Request-Forgery-(CSRF-)Angriffe aktivieren. Dazu muss lediglich das Backend ein entsprechendes Cookie (XSRF-TOKEN) in die Antworten einfügen. Angular erkennt dies und bettet den Tokenwert als proprietären Header (X-XSRF-TOKEN) in nachfolgende Anfragen ein (Abb. 4). Damit kann das Backend sicherstellen, dass Anfragen tatsächlich vom Angular Frontend stammen und nicht von einem unautorisierten Dritten. Die dazu erforderliche Konfiguration im Backend ist mit Spring Security denkbar einfach und in Listing 3 dargestellt. Dabei ist zu beachten, dass hier der Zugriff für JavaScript ausdrücklich aktiviert werden muss (withHttpOnlyFalse). Weitergehende Details zu CSRF sowie neuere Abwehrmöglichkeiten wie Samesite Cookies (aktuell nur vom Chrome-Browser unterstützt) sind hier nachzulesen.

Abb. 4: Double-Submit-CSRF-Token in Angular

Abb. 4: Double-Submit-CSRF-Token in Angular

@Configuration
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {
  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http.csrf().csrfTokenRepository(
      CookieCsrfTokenRepository.withHttpOnlyFalse()
    );
}

Wer bin ich? Authentifizierung im Spring Backend

Die Kombination von Spring Boot mit Spring Security bringt gerade in puncto Sicherheit eine gute, automatisch aktive Basiskonfiguration mit. Authentifizierung für alle implementierten HTTP(S)-Endpunkte ist Standard. Auch der Schutz vor Session Fixation ist integriert. Das heißt, dass die Session-Cookies nach der Authentifizierung immer mit neuen Werten generiert werden. Die Session-Cookies sind nicht per JavaScript abgreifbar (HTTPOnly-Flag) und lassen sich sicher übertragen, sobald HTTPS aktiviert ist (Secure-Flag). Alle empfohlenen Security Response Header sind gesetzt.

Die korrekte Authentifizierung und Autorisierung von Zugriffen gehört zu den essenziellen Security Controls auf der Serverseite. Microservices-Architekturen setzen als Authentifizierungsprotokolle hier in der Regel entweder Basic Authentication (zustandsbasiert mittels Session-Cookies) oder tokenbasierte Standards wie OAuth2 oder OpenID Connect 1.0 ein (zustandslos). Die wesentlichen Unterschiede zwischen Session-Cookies und Tokens sind in Tabelle 1 dargestellt. Die Tendenz geht hier aber eindeutig in Richtung tokenbasierter Lösungen. Das hat den Vorteil, dass die sensiblen Benutzerdaten Name und Passwort nicht in jedem Microservice einzeln verwaltet und gespeichert werden müssen, sondern nur noch an einem Punkt sicher verwahrt werden, dem Authorization-Server oder Identity-Provider. Ein weiterer Vorteil der Tokens ist die Immunität gegenüber CSRF-Angriffen. Beide Mechanismen übertragen sensitive Informationen und sollten immer mit HTTPS übertragen werden.

Session-Cookies Token (Bearer, JWT …)
Mit jedem Request vom Browser mitgesendet Manuell von der Anwendung als Header gesetzt
Gefahr von CSRF-Angriffen Kein CSRF möglich
Persistiert bei Seitenwechsel Keine automatische Speicherung
Auf eine Domain beschränkt Domainübergreifend (mit CORS)
Sensitive Informationen (HTTPS ist Pflicht) Sensitive Informationen (HTTPS ist Pflicht)

Tabelle 1: Authentifizierung per Session-Cookie oder Token

OAuth2 bringt die in Abbildung 5 dargestellte Aufteilung in vier Rollen (Resource Owner, Client, Authorization-Server, Resource-Server) und den Authorization Code Flow mit sich. Beim Zugriff auf die geschützte Ressource (hier Stack Overflow) wird über den Webbrowser ein Redirect zum Authorization-Server durchgeführt, z. B. Facebook oder Google. Dort wird der Benutzer authentifiziert und die Erlaubnis zur Freigabe der Daten für den Zugriff auf Stack Overflow eingeholt. Mit dem anschließend ausgestellten Access-Token ist der Zugriff auf den gewünschten Dienst möglich. Je nach Clienttyp (Server, JavaScript, Native App) stellt OAuth2 unterschiedliche Flows bereit.

Abb. 5: Autorisierungsfluss mit OAuth2

Abb. 5: Autorisierungsfluss mit OAuth2

Während OAuth2 im Internet als Autorisierungsprotokoll für den Zugriff auf bekannte Dienste wie Stack Overflow verwendet wird, reicht das für die in Unternehmensanwendungen üblicherweise erforderliche Authentifizierung nicht aus. Hier werden Identitätsinformation wie Vor- und Nachname, E-Mail oder Rollen/Rechte benötigt. In diesem Fall wird stattdessen das auf OAuth2 basierende Authentifizierungsprotokoll OpenID Connect 1.0 verwendet. Dieses Protokoll ergänzt OAuth2 neben dem Hybrid Flow um ein ID-Token, das für den Client bestimmt ist und auch die Identitätsinformationen enthält (Abb. 6). Das Access-Token wird weiterhin für den Zugriff auf Backend-Services verwendet. Optional wird auch ein Endpunkt zur Verfügung gestellt, mit dem ein Backend mithilfe des Access-Tokens weiterführende Benutzerdaten wie Rollen/Rechte abfragen kann. Eine Auswahl verfügbarer Identity-Provider-Implementierungen für OAuth2 und OpenID Connect ist in Tabelle 2 aufgelistet.

Abb. 6: Authentifizierungsfluss mit OpenID Connect 1.0

Abb. 6: Authentifizierungsfluss mit OpenID Connect 1.0

Spring Security OAuth implementiert aktuell lediglich OAuth 1.0 sowie OAuth2 mit JSON Web Tokens (JWT), nicht den vollständigen, für einen Identity Provider notwendigen OpenID-Connect-Standard. Daher wurde im aktuellen Projekt von Kundenseite der für OpenID Connect zertifizierte, auf .NET basierende IdentityServer3 als Identity Provider gesetzt. Er wird aktuell in der Microsoft Azure Cloud betrieben. Für die Implementierung der Microservices als Resource-Server wird Spring Security OAuth verwendet, da zumindest die im Backend erforderliche Validierung und Decodierung der JWT-Tokens dem OpenID-Connect-Standard folgen.

Aktuell wird vom Spring-Team evaluiert, wie die Standards OAuth2 und OpenID Connect aus dem bisherigen separaten Modul direkt in Spring Security integriert werden können. Vermutlich werden wir in der kommenden zu Spring 5 kompatiblen Spring-Security-Version erste Ergebnisse davon sehen. Neben den genannten Überlegungen wird Spring Security aktuell auch bezüglich des in Spring 5 integrierten reaktiven Webmoduls (Spring WebFlux) fit gemacht. Auf Clientseite wurde die OpenID-Connect-Unterstützung für Angular mit dem Implicit Flow im Projekt implementiert, da im Frühstadium der zahlreichen Betaversionen von Angular noch keine brauchbare Implementierung für TypeScript vorhanden war. Die Umsetzung wurde dabei nach den Empfehlungen von http://openid.net ausgeführt.

Produkt OAuth2 OpenID Connect
Spring Security OAuth 2.0 X
MITREid Connect X X
IdentityServer3/IdentityServer4 X X
Microsoft Azure Active Directory X X
Red Hat Keycloak X X

Tabelle 2: Eine Auswahl von Implementierungen für OAuth2 und OpenID Connect 1.0

Was darf ich? Autorisierung im Spring Backend

Die OWASP-Top-10-Liste der häufigsten Sicherheitsrisiken führt unsichere direkte Objektreferenzen auf Platz vier, direkt hinter Cross-Site Scripting. Diese Objektreferenzen sind gerade in den auf Serverseite häufig verwendeten RESTful Services weit verbreitet. Der Grund hierfür ist entweder in einer komplett fehlenden oder lückenhaften Autorisierung zu suchen. Spring Security bietet hierfür eine deklarative rollen- bzw. rechtebasierte Autorisierungsprüfung auf allen Anwendungsebenen an (Web, Servicemethoden und Datenzugriff). Wird beispielsweise auf dem Web Tier vergessen, einen bestimmten URL zu schützen, greift in der Regel immer noch eine der tieferen Ebenen. In Listing 4 wird ein Service mit statischer rollenbasierter Autorisierung auf Methodenebene implementiert. Neben den statischen @Secured-Annotationen können hier auch alternativ die @PreAuthorize– oder @PostAuthorize-Annotationen eingesetzt werden, die mit der Spring Expression Language (SpEL) auch dynamische Autorisierungsregeln auf Basis der Eingaben oder Ausgaben abbilden können.

@Service
public class DefaultHelloServiceImpl implements HelloService {
  @Secured( "ROLE_USER" )
  @Override
  public String user() {
    return "User access";
  }
  @Secured ( "ROLE_ADMIN" )
  @Override
  public String admin() {
    return "Admin access";
  }
}

Derartige Autorisierungsmodelle können in Unternehmensanwendungen schnell komplex werden. Mit dem Spring-Security-Test-Framework lässt sich ein solches Modell zum Glück gut automatisiert testen. Ein Integrationstest für den weiter oben definierten Service ist in Listing 5 dargestellt. Mithilfe der @WithMockUser-Annotationen lassen sich Benutzer mit deren Rollen und Rechten simulieren. Das lässt sich mittels Implementierung des vom Framework bereitgestellten Interface WithSecurityContextFactory auch für spezifische eigene Benutzer- und Rollenmodelle erweitern. Das RESTful API sollte über diese Integrationstests hinaus noch kontinuierlich durch entsprechende Securityscanner auf weitere Sicherheitslücken überprüft werden. Typische Werkzeuge hierfür sind Fuzzapi oder OWASP ZAP.

@RunWith(SpringRunner.class)
@SpringBootTest(classes = AuthorizationsDemoApplication.class)
public class MethodLevelAuthorizationTest {
  @Autowired
  private HelloService cut;

  @WithMockUser(roles = "ADMIN")
  @Test
  public void verifyAdminMethodGrantedForAdminRole() {
    assertThat (cut.admin ()).isEqualTo("Admin access");
  }

  @WithMockUser(roles = "USER")
  @Test(expected = AccessDeniedException.class)
  public void verifyAdminMethodDeniedForUserRole() {
    cut.admin ();
  }
}

Das Backend gegen unerlaubte Eingaben und SQL Injections abschotten

Um XSS-Angriffe gar nicht erst zum dauerhaften Problem werden zu lassen, sollten alle Inputs, die vom Client an die REST-Schnittstelle des Backends geschickt werden, geprüft werden, bevor sie weiter verarbeitet werden. Hierbei helfen im Backend zwei Schutzmaßnahmen: die exakte Typisierung aller Eingaben und die Validierung aller Eingaben. Die Parameter der REST-Schnittstelle sollten nicht einfach generisch alle mit dem String-Typ versehen werden. Wenn ein numerischer Wert erwartet wird, sollte auch ein Parameter, beispielsweise vom Typ Integer, definiert werden. Spring MVC übernimmt dabei die automatische Konvertierung aller Eingaben in die definierten Zieldatentypen. Ergänzend dazu werden die Eingaben mittels Bean Validation auf Gültigkeit überprüft. Das lässt sich wie bei der Autorisierung auf Ebene der REST-Schnittstelle sowie in den JPA Entity Beans überprüfen. Ein Beispiel ist in Listing 6 zu sehen.

@Entity
public class Person extends AbstractPersistable<Long> {
  @NotNull
  @Pattern(regexp = "^[A-Za-z0-9- ]{1,30}$")
  private String lastName;

  @NotNull
  @Enumerated(EnumType.STRING)
  private GenderEnum gender; 

}

Auch SQL Injections sind leider immer noch häufig in Anwendungen anzutreffen, obwohl sie mit relativ wenig Aufwand zu verhindern wären. Durch den verbreiteten Einsatz von ORM-Frameworks wie Hibernate und die automatisch generierten Abfragen in Spring Data JPA bekommt man die sicheren Prepared Statements geschenkt. SQL Injections sind damit nicht mehr möglich. Ein Beispiel parametrisierter sowie autogenerierter Abfragen mit Spring Data JPA ist in Listing 7 realisiert.

public interface UserRepository extends JpaRepository<User, Long> {
  // Parametrisierte Abfrage
  @Query("select u from User u where" + " u.username = :username and u.password = :password")
  User findByUsernameAndPassword(@Param("username") String username, @Param("password") String password);

  // Autogenerierte Abfrage
  User findByUsername(String username);
}

Ist die Cloud sicher?

Abschließend möchte ich noch die von Kunden oft gestellte Frage aufgreifen, ob die Cloud sicher ist. Eigentlich ist die Frage unpräzise formuliert, man sollte vielmehr fragen, inwiefern sich die Sicherheit mit der Cloud tatsächlich verändert. Generell hat man in der Cloud mit denselben Sicherheitsproblemen zu tun wie im On-Premise-Modell. Webanwendungen sollten auch in der Cloud gegen die hier im Artikel behandelten Angriffe abgesichert werden. Selbiges trifft auf die Verwendung schwacher Passwörter und unsicherer Verschlüsselungen zu.

Cloud Foundry ist im beschriebenen Projekt als Private-Cloud-Provider gesetzt. Justin Smith, Sicherheitsexperte bei der Firma Pivotal, beschreibt in seinem Vortrag“Cloud Native Security“ die Sicherheitsprinzipien der Cloud Foundry mit dem Slogan „Rotate, Repair, Repave“: Durch die Kombination von dynamischer Rotation von Zugangsdaten (cf bind myapp mysql), zeitnah eingespielten Security-Fixes und regelmäßigen Re-Deployments der eigenen Anwendungen inklusive Laufzeitcontainer (cf push myapp) wird die Angriffsfläche für Hacker weiter eingeschränkt. Die Bereitstellung von Security-Fixes bezieht sich dabei auf sämtliche Laufzeitkomponenten einer Anwendung in Cloud Foundry.

Lesen Sie auch: Spring Boot Tutorial: So entwickelt man REST-Services mit Spring Boot

Das beginnt bei der Infrastrukturabsicherung des IaaS-Providers (z. B. AWS) und endet bei der Spring-Plattform mit der eigenen Anwendung und deren Fremdbibliotheken. Diese (z. B. Hibernate oder Apache Commons) waren schon häufiger von Sicherheitsproblemen betroffen. Mit Spring Boot und der Spring-Plattform werden die Third-Party-Bibliotheken über das jeweilige Buildsystem gemeinsam konfiguriert und können alle gleichzeitig mittels Aktualisierung der Dependency zur Spring-Plattform auf die neusten gepatchten Versionen hochgezogen werden.

Darüber hinaus sollten auch die Dienste der Spring-Cloud-Module (u. a. Service Discovery, Circuit Breaker Dashboard und Config-Server) entsprechend gegen unberechtigten Zugriff abgesichert werden. Ansonsten könnte ein Angreifer der Service Discovery seinen eigenen Dienst unterschieben. Verwendet man die seit kurzem auch auf der öffentlichen Cloud von Pivotal (PWS) verfügbaren Spring Cloud Services, kann man auf Basis von OAuth2-Tokens fertig vorkonfiguriert nutzen.

Setzt man hingegen diese Services in Eigenregie auf, muss man selbst für die nötige Sicherheit sorgen. Im einfachsten Fall passiert das mittels Basic Authentication über HTTPS. Benötigt man in seiner Anwendung weitere sensible Konfigurationsdaten, kann man sie mithilfe eines Config-Servers verschlüsselt ablegen und beim Abruf automatisch entschlüsseln lassen:

mypassword={cipher}AQB5QTNM1kaOeF9c8gI5q/ovY0UvhIErDoom6av/fhXZkANW6...

Entsprechende Beispiele für die Absicherung der Services sowie die Ablage verschlüsselter Konfigurationswerte sind auf meiner GitHub-Seite zu finden.

Fazit

Das Sicherheitslevel moderner Webanwendungen lässt sich durch Frameworks wie Angular und Spring mit ihren eingebauten Sicherheitsmechanismen deutlich anheben. Wenn die Entwickler nicht mutwillig um die Frameworks herum programmieren, bieten diese sichere APIs und Konfigurationen out of the Box. So sollten in Angular keine der ausdrücklich als unsicher eingestuften Funktionen im Programmcode verwendet werden. In Spring Security müssen die sicheren Grundkonfigurationen explizit deaktiviert werden. Das lässt sich durch automatisierte statische Codeanalysen und manuelle Code-Reviews laufend überprüfen. Darüber hinaus muss durch Protokollierung und Monitoring sichergestellt werden, dass potenzielle Angriffsmuster (u. a. XSS, DoS, Brute Forcing) frühzeitig erkannt werden. Dies kann durch produktionsunterstützende Features von Spring Boot umgesetzt werden.

Sehen Sie auch: Spring 5: Diese Features machen das Framework zukunftssicher [Video]

Auch die Cloud ist in puncto Sicherheit kein Allheilmittel. Insbesondere befreit sie die Entwickler nicht von der Pflicht, ihre Anwendungen mit der notwendigen Sicherheit zu versehen. Auch die Sicherung der Kommunikationsstrecken durch HTTPS ist in der Cloud Pflicht. Hier wird häufig durch den Einsatz selbstsignierter Zertifikate gespart. Den heutzutage relativ kostengünstigen – mit Let’s Encrypt sogar kostenlosen – durch eine CA offiziell validierten Zertifikaten stehen häufig unnötig hohe Entwicklungskosten für unsichere Workarounds in der Anwendung im Umgang mit den selbstsignierten Varianten gegenüber.

Geschrieben von
Andreas Falk
Andreas Falk
Andreas Falk arbeitet als Managing Consultant bei der NovaTec Consulting GmbH. Neben der Entwicklung von Unternehmensanwendungen auf Basis der Spring-Plattform oder mit Java EE beschäftigt er sich als OWASP-Mitglied außerdem mit der Anwendungssicherheit. Twitter: @andifalk
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.