Preventing SQL Injections in Java With JPA and Hibernate

published also on DZone 09.2022

published also on DZone 09.2022

When we have a look at OWASP’s top 10 vulnerabilities [1], SQL Injections are still in a popular position. In this short article, we discuss several options on how SQL Injections could be avoided.

When Applications have to deal with databases existing always high-security concerns, if an invader got the possibility to hijack the database layer of your application, he can choose between several options. Stolen the data of the stored users to flood them with spam is not the worst scenario that could happen. Even more problematic would be when stored payment information got abused. Another possibility of an SQL Injection Cyber attack is to get illegal access to restricted pay content and/or services. As we can see, there are many reasons why to care about (Web) Application security.

To find well-working preventions against SQL Injections, we need first to understand how an SQL Injection attack works and on which points we need to pay attention. In short: every user interaction that processes the input unfiltered in an SQL query is a possible target for an attack. The data input can be manipulated in a manner that the submitted SQL query contains a different logic than the original. Listing 1 will give you a good idea about what could be possible.

SELECT Username, Password, Role FROM User
   WHERE Username = 'John Doe' AND Password = 'S3cr3t';
SELECT Username, Password, Role FROM Users
   WHERE Username = 'John Doe'; --' AND Password='S3cr3t';

Listing 1: Simple SQL Injection

The first statement in Listing 1 shows the original query. If the Input for the variables Username and Password is not filtered, we have a lack of security. The second query injects for the variable Username a String with the username John Doe and extends with the characters ‘; –. This statement bypasses the AND branch and gives, in this case, access to the login. The ‘; sequence close the WHERE statement and with — all following characters got un-commented. Theoretically, it is possible to execute between both character sequences every valid SQL code.

Of course, my plan is not to spread around ideas that SQL commands could rise up the worst consequences for the victim. With this simple example, I assume the message is clear. We need to protect each UI input variable in our application against user manipulation. Even if they are not used directly for database queries. To detect those variables, it is always a good idea to validate all existing input forms. But modern applications have mostly more than just a few input forms. For this reason, I also mention keeping an eye on your REST endpoints. Often their parameters are also connected with SQL queries.

For this reason, Input validation, in general, should be part of the security concept. Annotations from the Bean Validation [2] specification are, for this purpose, very powerful. For example, @NotNull, as an Annotation for the data field in the domain object, ensure that the object only is able to persist if the variable is not empty. To use the Bean Validation Annotations in your Java project, you just need to include a small library.

<dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>${version}</version>
</dependency>

Listing 2: Maven Dependency for Bean Validation

Perhaps it could be necessary to validate more complex data structures. With Regular Expressions, you have another powerful tool in your hands. But be careful. It is not that easy to write correct working RegEx. Let’s have a look at a short example.

public static final String RGB_COLOR = "#[0-9a-fA-F]{3,3}([0-9a-fA-F]{3,3})?";

public boolean validate(String content, String regEx) {
    boolean test;
    if (content.matches(regEx)) {
        test = true;
    } else {
        test = false;
    }
    return test;
}

validate('#000', RGB_COLOR);

Listing 3: Validation by Regular Expression in Java

The RegEx to detect the correct RGB color schema is quite simple. Valid inputs are #ffF or #000000. The Range for the characters is 0-9, and the Letters A to F. Case insensitive. When you develop your own RegEx, you always need to check very well existing boundaries. A good example is also the 24 hours time format. Typical mistakes are invalid entries like 23:60 or 24:00. The validate method compares the input string with the RegEx. If the pattern matches the input, the method will return true. If you want to get more ideas about validators in Java, you can also check my GitHub repository [3].

In resume, our first idea to secure user input against abuse is to filter out all problematic character sequences, like — and so on. Well, this intention of creating a blocking list is not that bad. But still have some limitations. At first, the complexity of the application increased because blocking single characters like –; and ‘ could causes sometimes unwanted side effects. Also, an application-wide default limitation of the characters could cost sometimes problems. Imagine there is a text area for a Blog system or something equal.

This means we need another powerful concept to filter the input in a manner our SQL query can not manipulate. To reach this goal, the SQL standard has a very great solution we can use. SQL Parameters are variables inside an SQL query that will be interpreted as content and not as a statement. This allows large texts to block some dangerous characters. Let’s have a look at how this will work on a PostgreSQL [4] database.

DECLARE user String;
SELECT * FROM login WHERE name = user;

Listing 4: Defining Parameters in PostgreSQL

In the case you are using the OR mapper Hibernate, there exists a more elegant way with the Java Persistence API (JPA).

String myUserInput;

@PersistenceContext
public EntityManager mainEntityManagerFactory;

CriteriaBuilder builder =
    mainEntityManagerFactory.getCriteriaBuilder();

CriteriaQuery<DomainObject> query =
    builder.createQuery(DomainObject.class);

// create Criteria
Root<ConfigurationDO> root =
    query.from(DomainObject.class);

//Criteria SQL Parameters
ParameterExpression<String> paramKey =
    builder.parameter(String.class);

query.where(builder.equal(root.get("name"), paramKey);

// wire queries together with parameters
TypedQuery<ConfigurationDO> result =
    mainEntityManagerFactory.createQuery(query);

result.setParameter(paramKey, myUserInput);
DomainObject entry = result.getSingleResult();

Listing 5: Hibernate JPA SQL Parameter Usage

Listing 5 is shown as a full example of Hibernate using JPA with the criteria API. The variable for the user input is declared in the first line. The comments in the listing explain the way how it works. As you can see, this is no rocket science. The solution has some other nice benefits besides improving web application security. At first, no plain SQL is used. This ensures that each database management system supported by Hibernate can be secured by this code.

May the usage looks a bit more complex than a simple query, but the benefit for your application is enormous. On the other hand, of course, there are some extra lines of code. But they are not that difficult to understand.

Resources

[1] https://owasp.org
[2] https://beanvalidation.org
[3] https://github.com/ElmarDott/TP-CORE/blob/master/src/main/java/org/europa/together/utils/Validator.java
[4] https://www.postgresql.org/docs/9.1/plpgsql-declarations.html
[5] https://hibernate.org
[6] Seminar: Web-Application Security

Network spy protection with AdGuard Home on a Raspberry Pi and Docker

Maybe you have bought you like me an Raspberry Pi4 with 4GB RAM and think about what nice things you could do with it. Since the beginning I got the idea to use it as an lightweight home server. Of course you can easily use a mini computer with more power and obviously more energy consumption too. Not a nice idea for a device is running 24/7. As long you don’t plan to mine your own bitcoins or host a high frequented shop system, a PI device should be sufficient.

I was wanted to increase the network security for my network. For this reason I found the application AdGuard which blocks many spy software from internet services you use on every device is connected to the network where AdGuard is running. Sounds great and is not so difficult to do. Let me share with you my experience.

As first let’s have a look to the overall system and perquisites. After the Router from my Internet Service Provider I connected direct by wire my own Network router an Archer C50. On my Rapsbery PI4 with 4GB RAM run as operation system Ubuntu Linux Server x64 (ARM Architecture). The memory card is a 64 GB ScanDisk Ultra. In the case you need a lot of storage you can connect an external SSD or HDD with an USB 3 – SATA adapter. Be aware that you use a storage is made for permanent usage. Western Digital for example have an label called NAS, which is made for this purpose. If you use standard desktop versions they could get broken quite soon. The PI is connected with the router direct by LAN cable.

The first step you need to do is to install on the Ubuntu the Docker service. this is a simple command: apt-get install docker. if you want to get rid of the sudo you need to add the user to the docker group and restart the docker service. If you want to get a bit more familiar with Docker you can check my video Docker basics in less than 10 minutes.

sudo apt-get install docker
sudo gpasswd -a <user> docker
sudo dockerd

After this is done you need to create a network where the AdGuard container is reachable from your router to a static IP address on your PI.

docker network create -d macvlan -o parent=eth0 \
--subnet=192.168.0.0/16 \
--ip-range=192.168.0.4/25 \
--gateway=192.168.0.1 \
lan

Before you just copy and past the listing above, you need to change the IP addresses to the ones your network is using. for all the installation, this is the most difficult part. As first the network type we create is macvlan bounded to the network card eth0. eth0 is for the PI4 standard. The name of the network we gonna to create is lan. To get the correct values for subnet, ip-range and gateway you need to connect to your router administration.

To understand the settings, we need a bit of theory. But don’t worry is not much and not that complicated. Mostly your router is reachable by an IP address similar to 192.168.0.1 – this is a static address and something equal we want to have for AdGuard on the PI. The PI itself is in my case reachable by 192.168.0.12, but this IP we can not use for AdGuard. The plan is to make the AdGuard web interface accessible by the IP 192.168.0.2. OK let’s do it. First we have to switch on our router administration to the point DHCP settings. In the Screenshot you can see my configuration. After you changed your adaptions don’t forget to reboot the router to take affect of the changes.

I configured the dynamic IP range between 192.168.0.5 to 192.168.0.199. This means the first 4 numbers before 192.168.0.5 can be used to connect devices with a static IP. Here we see also the entry for our default gateway. Whit this information we are able to return to our network configuration. the subnet IP is like the gateway just the digits in the last IP segment have to change to a zero. The IP range we had limited to the 192.168.0.4 because is one number less than where we configured where the dynamic IP range started. That’s all we need to know to create our network in Docker on the PI.

Now we need to create in the home directory of our PI the places were AdGuard can store the configuration and the data. This you can do with a simple command in the ssh shell.

mkdir /home/ubuntu/adguard/work
mkdir /home/ubuntu/adguard/conf

As next we have to pull the official AdGuard container from the Docker Hub and create a image. This we do by just one command.

docker run -d --name adguard --restart=always \
-p 3000:3000/tcp --net lan --ip 192.168.0.2 \
-p 53/tcp -p 53/udp -p 67/udp -p 68/udp -p 80/tcp \
-p 784/udp -p 8853/udp \
-p 443/tcp -p 443/udp \
-p 853/tcp -p 853/udp \
-p 5443/tcp -p 5443/udp \
-v /home/ubuntu/adguard/work:/opt/adguardhome/work \
-v /home/ubuntu/adguard/conf:/opt/adguardhome/conf \
adguard/adguardhome:latest

The container we create is called adguard and we connect this image to our own created network lan with the IP address 192.168.0.2. Then we have to open a lot of ports AdGuard need to do the job. And finally we connect the two volumes for the configuration and data directory inside of the container. As restart policy we set the container to always, this secure that the service is up again after the server or docker was rebooted.

After the execution of the docker run command you can reach the AdGuard configuration page with your browser under: http://192.168.0.2:3000. Here you can create the primary setup to create a login user and so on. After the first setup you can reach the web interface by http://192.168.0.2.

The IP address 192.168.0.2 you need now to past into the field DNS Server for the DHCP settings. Save the entries and restart your router to get all changes working. When the router is up open on your browser any web page from the internet to see that everything is working fine. After this you can login into the AdGuard web console to see if there appearing data on the dashboard. If this is happened then you are don e and your home or office network is protected.

If you think this article was helpful and you like it, you can support my work by sharing this post or leave a like. If you have some suggestions feel free to drop a comment.

Sicherheit und Datenschutz in verteilten Netzwerken

Der Erfolg des Internet-Service Cloud umfasst verschiedene Aspekte, von denen der schwergewichtigste Grund für diese neue Technologie, mit weitem Abstand monetär motiviert ist. Die finanzielle Planungssicherheit bei den Investitionskosten für die Infrastruktur seitens der Nutzer besticht ebenso zur Cloud Migration, wie das zentralisierte Ausliefern der Dienste seitens der Anbieter. Dennoch gibt es bei all den positiven Sichtweisen auf die Cloud einen wichtigen Faktor, der eine rasante Verbreitung flächendeckender Lösungen abmildert. Die im Jahre 2013 durch Edward Snowden veröffentlichten Informationen über die amerikanische Spionage gegenüber der gesamten Welt, veranlasste besonders im europäischen Raum, heftige Debatten seitens der Politik über Sicherheit und Datenschutz. Da Cloud Services zum größten Teil auf Netzwerktechnologie basiert und die derzeit größten Anbieter amerikanische Unternehmen sind, haben die Enthüllungen Snowdens das Vertrauen in die neue Technologie nachhaltig erschüttert. Die Forderungen nach einer Europäischen Lösung sollte die Problematik des Datenschutzes neu adressieren und für zukünftige Innovationen der IT Branche die Signale in Richtung freier Fahrt stellen. In der nachfolgenden Ausarbeitung werden unterschiedliche Facetten der IT Sicherheit betrachtet. Dabei ist das Augenmerk größtenteils auf Hintergründe, Zusammenhänge und politischem Background gerichtet. Technische Konzepte werden an den entsprechenden Stellen nur kurz angedeutet und auf die entsprechenden Quellen verwiesen, da besonders im Bereich der Web – Technologien viele Gefahren bereits gelöst sind.

(c) 2014 – Marco Schulz & Pascal Werkl, Seminararbeit der TU Graz

Datenschutz und Überwachung

Als im Sommer 1989 die Bürger der Deutschen Demokratischen Republik auf die Straßen gegangen sind, haben sie ihren Unmut gegen ein System zum Ausdruck gebracht, dass die Rechte des Einzelnen auf persönliche Selbstbestimmung und Meinungsfreiheit auf das sträflichste missachtet hat. Mit der Organisation Staatssicherheit (STASI) wurde über Jahre eine allmächtige Institution geschaffen, die abseits aller Legitimation, willkürlich die Schicksale vieler Menschen negativ beeinflusst hat. Unter dem Deckmantel der Friedenssicherung wurde die gesamte Bevölkerung systematisch erfasst und überwacht. Mit den gewonnenen Erkenntnissen wurden gegen Kritiker der Diktatur verschiedenste Maßnahmen zur Willensbrechung in die Wege geleitet. Mit gezielten Aktionen, die beruflichen und privaten Misserfolg förderten, sollten so die “subversiven Elemente” gebrochen werden. Die Intensität solcher Maßnahmen wurde nicht selten so weit getrieben, dass die Opfer keinen anderen Ausweg als den Suizid fanden. Langjährige Haftstrafen für Gegner des totalitären Regimes waren die traurige Regel und selbst vor Mord schreckte das System nicht zurück. Man sollte sich dessen bewusst sein, dass die Vorgehensweisen der STASI lediglich eine Weiterentwicklung der Methoden sind, derer sich die deutsche Gestapo bediente um den Holocaust zu inszenieren. Bereits diese historisch dokumentierten Tatsachen aus jüngster Geschichte sollte der breiten Öffentlichkeit die Augen öffnen um alle Möglichkeiten auszuschöpfen, eine totale Überwachung durch staatliche oder private Institutionen zu verhindern. Wohin ein solcher Weg führen kann hat George Orwell in seinem Roman “1984” aufgezeigt, der in den 1940 ‘er Jahren unter den Eindrücken des 2. Weltkrieges entstanden ist.

Mit den schlimmen Terroranschlägen vom 11. September 2001 gegen die USA und dem damit verbundenen Kampf gegen den Terror, haben viele Staaten in jüngster Vergangenheit eine Reihe an Gesetzen auf den Weg gebracht, die die Persönlichkeitsrechte des Einzelnen missachten und somit auch die Demokratie gefährden. Die Vorratsdatenspeicherung, welche sämtliche Kommunikationsdaten wie E-Mail, SMS und Mobiltelefonie für mindestens 6 Monate vorhält, ist ein verehrendes Beispiel, wie eine gesamte Bevölkerung unter Generalverdacht gestellt wird. Moderne Algorithmen1, die auf solchen Informationen operieren, können Menschen vollautomatisch klassifizieren. Die gewonnenen Erkenntnisse können dann wiederum herangezogen werden, um beispielsweise einzelnen Gruppen den Zugang zu Bildung, korrekte medizinische Betreuung oder den Erwerb von Eigentum zu erschweren oder ganz zu versagen. Wie bereits aufgezeigt, hat die Geschichte mehrfach bewiesen, dass solche Überlegungen nicht aus der Luft gegriffen sind. Im heutigen Informationszeitalter besteht zusätzlich die Möglichkeit einer gezielten Manipulation des Einzelnen. Das heißt diesen der öffentlichen Meinung anzugliedern, indem er anhand der gesammelten Daten über Psychologie- als auch Marketing-Strategien mit der Masse gleichgeschaltet wird. In der heutigen Gesellschaft sind die meisten Protagonisten vollständig digital vernetzt. Über online Einkäufe, Kreditkarten, elektronische Abonnements für Multimedia wie Spiele, Musik, Bücher und Filme, Soziale Netzwerke, Telefonate und E-Mail generiert ein jeder Mensch unbedacht eine Vielzahl von Daten, an denen Industrie und Politik aus unterschiedlichsten Gründen gesteigertes Interesse haben. Sofern es einen, wenn auch vorerst stark eingeschränkten, gesetzlichen Rahmen zur Verknüpfung verschiedenster Informationen zu einer zentralen Datenbank gibt, ist es eine Frage der Zeit bis Institutionen, für die ein Zugriff nie vorgesehen war, ihren Anspruch auf diese Information fordern und höchstwahrscheinlich auch erhalten werden. Ein erschreckend Beispiel dafür ist die in Deutschland eingeführte Maut für LKW und Bus auf Autobahnen. Regelmäßig flammt die Debatte darüber auf, ob die durch die Maut erhobenen Daten auch zur Verkehrsüberwachung heran gezogen werden dürfen. Der Gesetzgeber erhofft sich dadurch eine leichtere Kontrolle und Ahndung von Verstößen wie Geschwindigkeitsüberschreitungen und zulange Lenkzeiten. Auf den ersten Blick mag dies wie eine sehr wirkungsvolle Maßnahme zur Unfallvorbeugung erscheinen. Bei näherer Betrachtung ist die ein weiterer Schritt zu einer technokratischen Gesellschaft, die lediglich zwischen schwarz und weiß unterscheidet und jeglichen Individualismus unterbindet. Ein Beamter, der vor Ort mit einer Situation konfrontiert wird, kann individuell das Geschehen beeinflussen. Eine Entscheidung nach Aktenlage, ist eine so starke Abstraktion das sie kaum den Menschen im Mittelpunkt haben kann, sondern eher dazu dient eine schnelle und kostengünstige Abwicklung zu ermöglichen. In vielen Bereichen unseres täglichen Lebens werden bereits Entscheidungen von Computersystemen getroffen, ohne das uns dies tatsächlich bewusst ist.

Um ein tieferes Verständnis der vorhandenen Probleme zu erhalten, begeben wir uns im nächsten Abschnitt auf die technische Ebene.

Das kleine Hacker Einmaleins

Betrachten wir als Beispiel den Service E-Mail, über den mittlerweile der größte Teil unserer Kommunikation läuft. Die gängigen Protokolle für E-Mail sind SMTP, POP3 und IMAP, die selbst keinen direkten Verschlüsselungsstandard verwenden und die gesamte Nachricht im Klartext übertragen. Ohne zusätzliche Maßnahmen ist es möglich, das eine dritte unbekannte Partei, durch Mitschneiden des Netzwerkverkehres die Nachricht liest. Die nachfolgende Abbildung zeigt die üblichen Stufen beim E-Mail-Versand.

Phasen der E-Mailkommunikation

Abbildung 1: Phasen der E-Mail Kommunikation

Im ersten Schritt verbindet sich ein Nutzer mit seinem E-Mail Provider über einen Client wie Thunderbird und Outlook oder er nutzt über den Browser das Webinterface des Providers. Um nun eine gesicherte Verbindung zwischen Sender und Empfänger zu etablieren nutzt der Provider die Transportschicht des TCP / IP Protokolls in dem er auf den Secure Socket Layer (SSL) zugreift. Diese Maßnahme verschlüsselt die Kommunikation zwischen Sender und Empfänger, so dass die im Netzwerk übertragenen TCP Pakete nicht mehr im Klartext zu lesen sind. Das ist auch der klassische Weg, wie in öffentlich genutzten Netzwerken Login Daten vor dem Ausspähen mittels TCP Sniffing geschützt werden. Eine SSL Verbindung erkennt man in der Adresszeile des Browsers durch das https Protokoll. Sobald der Provider die E-Mail zu Weiterleitung erhalten hat, ist er in der Lage den Inhalt auszulesen. Auf dem Server des Providers durchläuft die E-Mail nun verschiedene Filter, die sicherstellen sollen dass es sich weder um Spam noch um Maleware handelt, was im Übergang von Schritt 1 auf 2 dargestellt ist. Erst bei erfolgreichem Passieren der Filter wird Schritt 3 ausgeführt und die E-Mail zum Empfänger Provider weiter geleitet. Auch bei diesem Transfer erfolgt die Übertragung über eine SSL Verbindung. Der Provider des Empfängers filtert die E-Mail ebenfalls und stellt diese dann endgültig zu. Während des gesamten Übertragungsprozesses sind auch Server Systeme beteiligt, die nicht direkt mit dem verwendeten Dienst in Verbindung stehen und einzig als Relay-Station die E-Mail zum nächsten Knoten weiter transportieren.

Inländische Internet Service Provider (ISP) sind von der Europäischen Union per Gesetz dazu verpflichtet für mindestens 6 Monate die IP Adresse des Senders und des Empfängers als auch Datum und Uhrzeit der Kommunikation zu speichern. Damit wurde die EU Richtlinie 2006/24/EG2 in geltendes nationales Recht umgesetzt. Anhand der gesammelten Informationen besteht nun die Möglichkeit ein umfassendes Bewegungsprofil und Kontaktprofil der betroffenen Personen zu generieren, denn die gespeicherten IP Adressen beinhalten automatisch die Standortinformation der Kommunikationspartner. Auch wenn die Nachricht selbst verschlüsselt Kist, besteht die Möglichkeit die META-Informationen des Senders und Empfängers auszulesen. Eine mögliche Option zumindest den Sender gegen neugierige Augen zu verschleiern wäre es, diesen im verschlüsselten Bereich der Nachricht zu übertragen. Eine solche Maßnahme hat allerdings nur geringe, beziehungsweise keine Wirkung, da durch die Natur von TCP /IP der Sender bekannt sein muss um eine Verbindung etablieren zu können. Zudem müsste die gesamte Dechiffrierung und anschließende Scans gegen Maleware direkt beim Empfänger vorgenommen werden. Das bedeutet für die Einzelnen Nutzer wiederum eine enorme Verantwortung die eigenen Systeme aktuell zu halten.

E-Mail Header

Abbildung 2: E-Mail Header

Für den Fall das die Nachricht direkt über das Web Interface des Providers gelesen wird bieten moderne Kryptographie Verfahren geringe Sicherheit, da man auf die Rechtschaffenheit des Providers angewiesen ist. Es besteht hier die Gefahr, dass im Code des Providers Schadcode versteckt ist, der die dechiffrierte Nachricht im Browser auslesen kann und an beliebige dritte Personen weiterleitet. Das Verstecken von Exploits auf viel besuchten Onlinediensten gehört zu den Grundfähigkeiten geübter Hacker.

Besonders Problematisch ist die Verwendung von Smart Devices wie Tablets und Telefonen im lokalen Netzwerk. Oft begreifen Endanwender das Risiko, welches von dieser Geräteklasse ausgeht nicht und haben kaum einen sicheren Schutz gegen unbefugte Benutzung eingerichtet. So sucht man auf diesen Geräten Virenscanner oder Firewalls, wie sie auf herkömmlichen Desktop Computern üblich sind vergebens. Das Risiko wird durch die Verwendung gerooteter Geräte maßgeblich verschärft, da durch diese Modifikation der Sicherheitsmechanismus des Betriebssystems ausgehebelt wird. Dieses Verhalten ist meist der Tatsache geschuldet, dass Benutzerfreundlichkeit und Sicherheit konträre Anforderungen sind. Die Gefahr besteht nun darin, das durch den mangelnden Schutz der Smart Devices, diese sehr leicht korrumpiert werden können, um dann im Netzwerk bei der Datensynchronisation weitere Geräte zu infizieren.

Abbildung 3: Typen der Cloud.

Abbildung 3: Typen der Cloud.

Ein minimaler Schutz gegen diese Bedrohung ist das Erkennen ob die im Netzwerk miteinander kommunizierenden Geräte bereits Modifizierungen wie ROOTEN aufweisen. Die Verweigerung Geräte im Netzwerk zu etablieren, die in der eigenen Umgebung mit einem besonders privilegierten Benutzer operieren, sollte gerade für Unternehmen die Minimalanforderung der internen Sicherheitsregeln sein. Aus diesem Grund ist es unerheblich ob es sich um eine private, public, community oder hybrid Cloud handelt, wie sie in Abbildung 3 dargestellt sind. Wegen der starken Synchronisierung zwischen den verschiedensten Geräten ist auch in geschlossenen Clouds ein hoher Sicherheitsstandard erforderlich. Gerade kabellose Funktechniken wie Wireless LAN (W-LAN) oder Powernet, dem Internet aus der Steckdose, ermöglichen bei unzureichender Konfiguration einiges an Angriffsmöglichkeiten. Als beispielsweise W-LAN etabliert wurde, waren viele Netzwerke nicht geschützt so das zu dieser Zeit das sogenannte War Driving eine populäre Freizeitbeschäftigung für technikbegeisterte Jugendliche darstellte. Auch heute existieren noch immer viele Netzwerke, bei denen man ohne eine erzwungene Authentifizierung bereits für den vollen Zugriff autorisiert ist. In den letzten Jahren haben die Betreiber auf diese Problematik reagiert und liefern an ihre Kunden sichere vorkonfigurierte Geräte aus.

Gründe für die Cloud

Cloud computing is a new way of delivering computing resources, not a new technology.”

Cloud Dienste lassen sich in die Bereiche Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS) unterteilen. Die folgende Grafik zeigt dabei welche Sektionen durch den Anbieter beziehungsweise durch den Nutzer verwaltet werden. Für Sicherheitsbetrachtungen ist besonders SaaS von großem Interesse, da hier der Nutzer am wenigsten Einfluss nehmen kann.

Abbildung 4: Varianten der Cloud-Schichten

Abbildung 4: Varianten der Cloud-Schichten

Das komplexe Anwendungen keine reinen Desktop Lösungen mehr sein müssen, sondern durchaus als Thin Client im Browser umgesetzt werden können, hat Google mit seinem kostenfreien Dienst Docs unlängst bewiesen. So lässt es sich leicht vorstellen, dass Softwarehersteller Ihre Produkte in Zukunft vermehrt als Cloud Solution vertreiben. Diese Vision lässt sich hervorragend mit den Cloud Ebenen IaaS, PaaS sowie SaaS weiterentwickeln, wobei der Fokus vermehrt auf Software as a Service (SaaS) liegt. SaaS bietet für die verschiedensten Szenarien wie Business to Business (B2B) und Business to Customer (B2C) hervorragende Ansätze. So ist es ist denkbar, dass beispielsweise ein bekannter Hersteller für Bildbearbeitung sein Portfolio hin zur Cloud migriert. Damit eröffnen sich diesem Unternehmen verschiedenste Perspektiven ihre Dienste erfolgreich zu vermarkten.

Privatanwender, welche die enormen Anschaffungskosten für die Desktop Installation nicht aufbringen können, erhalten einen legalen Zugang über ein Pay per Use Lizenzmodell. Selbständige, Professionelle Nutzer und Unternehmen buchen die benötigten Dienste als Flatrate für verschiedene Zeiträume. Zudem besteht noch die Option eine Auswahl an Web-Services oder ganzen Prozessketten anderen Unternehmen bereitzustellen, die diese Dienste in Ihren eigenen Applikationen verwenden. Somit könnte beispielsweise eine Onlinedruckerei auf ihrem Onlineportal ihren Kunden einen zugekauften Service zur digitalen Bildbearbeitung anbieten, um damit das eigene Produkt aufwerten, ohne das eigentliche Kerngeschäft durch Nebenkriegsschauplätze zu vernachlässigen.

Neben diesen offensichtlichen Vorteilen ist besonders die nichtfunktionale Anforderung Sicherheit ein markanter Punkt, der gesonderte Aufmerksamkeit verlangt. Die nachfolgenden Abschnitte beleuchten die notwendigen Aspekte zu Risiken, Erkennung und Analyse detaillierter.

Angriffsvektoren für Web Applikationen

Es gibt verschieden Gründe, weswegen Attacken auf Webdienste ausgeführt werden. Der einfachste und harmloseste Grund ist der Spieltrieb des Angreifers. Ein anderer Zugang ist der Wunsch einen Service kostenlos konsumieren zu können, wie es Captain Crunch alias J. T. Draper mit einer Spielzeugpfeife geschafft hat bei AT & T kostenlos zu telefonieren. Steve Woizniak, Erfinder des Apple, entwickelte darauf hin die Little Blue Box. Mit diesem Frequenzgenerator konnten gezielt Töne erzeugt werden, mit denen sich Telefone manipulieren ließen. Diese Technologie wurde später zum fernsteuern von Anrufbeantwortern verwendet. In den 1990‘ern erreichte Kevin Mitnick über Social Engineering, Zugriff auf verschiedenste IT-Systeme, was ihm eine mehrjährige Freiheitsstrafe einbrachte.

Auf 125 Seiten klärt die European Network and Information Securitry Agency (enisa) in ihrem Paper aus dem Jahre 2009 über Nutzen, Risiken und Empfehlungen zu Datensicherheit im Cloud Computig3 auf. Auf der Webseite der enisa stehen alle bisherigen Veröffentlichungen unter dem Punkt Publications zur Verfügung. Mittlerweile ist die Liste der von der enisa herausgebrachten Publikationen auf eine beachtliche Länge herangewachsen. Eine sehr kompakte Übersicht dieser Thematik zeichnet das Paper von Gail-Joon Ahn et al „Security and Privacy Challenges in Cloud Computing Environments“ 4 aus dem Jahre 2010.

Problematisch sind Angriffe, die darauf abzielen ein einen Service einzudringen und diesen dann beispielsweise für Massen E-Mails zu missbrauchen oder Schadcode zu verbreiten. Manchmal dienen solche Angriffe auch dazu Kundendaten abzugreifen, die dann gern beispielsweise für Kreditkartenmissbrauch verwendet werden. Eine sehr einfach auszuführende Klasse von Angriffen sind Denail of Service (DoS), mit denen bewirkt wird, dass ein Dienst nicht erreichbar ist. Dieses Vorgehen ist besonders für Unternehmen interessant, die ihre Marktposition ausbauen wollen, in dem sie die Angebote des Konkurrenten für die Zielgruppe unerreichbar machen.

Das größte Gefährdungspotenzial ist beim Datenschutz angesiedelt und beinhaltet die Themen Wirtschafts – beziehungsweise Industrie- Spionage. Unternehmen in Deutschland haben die Möglichkeit beim Bundesamt für Sicherheit in der Informationstechnik, Abteilung 2 über Maßnahmen der Spionageabwehr beraten und bei der Umsetzung unterstützt zu werden. Die Problematik über die Wahrung von Firmengeheimnissen ist vielen Unternehmen kaum bewusst. Am Beispiel der Firma Enercon zeigt sich jedoch schnell, welche enormen finanziellen Schäden verursacht werden können. Es kommt allerdings sehr selten vor, das Fälle von Wirtschaftsspionage publik werden, da oft die betroffenen Unternehmen ungern zugeben dass sie Lücken im Sicherheitsmodell hatten. Im Fall Enercon wurde auf Jahre hinaus der Zugang zum amerikanischen Markt versagt und eine Klage wegen Patentrechtsverletzung konnte im letzten Moment abgewehrt werden.

Security Testing

Dieser Abschnitt beschreibt wie Faktoren erkannt werden können, die sich problematisch auf die Sicherheit von Web Anwendungen auswirken. Es wird nicht geklärt, weswegen bestimmte Umstände sich als Risikoreich erweisen können, dazu sei auf die umfangreich verfügbare Literatur verwiesen. Eine wichtige Tatsache ist die Unterscheidung zwischen Server Sicherheit und Applikationssicherheit. Gerade die Serverkonfigurationen zwischen Entwicklungsmaschinen und Live Systemen unterscheiden sich erheblich. Teilweise können Programme nicht ausgeführt werden weil Funktionen deaktiviert wurden. Aus diesem Grund ist eine optimale Testinstanz für ein Projekt ein exakter Clone des Live Systems. Was allerdings wegen mangelnder Lizenzen selten umgesetzt werden kann.

Ein kleines Beispiel zur Serverkonfiguration ist die Option register_globals der Scriptsprache PHP. Durch das Deaktivieren dieser Option können Variablen nicht mehr einfach per URL an das Script weiter gereicht werden. Dadurch wird der Entwickler gezwungen Formularparameter über $_GLOBALS, $_GET oder $_POST auszuwerten. Als Provider mit der Migration von PHP 4 auf PHP 5 abgeschlossen hatten, konnten wegen der geänderten Konfiguration über Nacht viele Webseiten nicht mehr korrekt ausgeführt werden konnten.

Mit der richtigen Netzwerkkarte und dem Aircrack Framework ist es möglich den WPA und WEP Schlüssel von W-Lan Netzwerken zu brechen. Diese Attacke ist besonders verheerend, wenn der Angreifer den Datenverkehr im Netzwerk mitschneidet. Allein diese Möglichkeit zeigt auch sehr eindrucksvoll, dass die Services einer private Cloud ebenso gut gesichert sein sollten wie in public Clouds.

Auch der Erfolg von DoS Angriffen ist abhängig von der Serverkonfiguration, mit network intrusion prevention and detection Systemen wie SNORT können viele Angriffe abgewehrt werden. Um sicherzustellen, dass Dienste eine Mindestmenge an Anfragen bewältigen können, werden diese mittels Penetration Tests bewertet. Mit den gewonnenen Erkenntnissen kann eine Aussage getroffen werden, ob die verfügbaren Ressourcen ausreichend sind. Mit Backtrack Linux existiert eine Distribution, die bereits eine Vielzahl an nützlichen Werkzeugen zusammen gestellt hat um Penetration Testing zu betreiben. Im Gegensatz zu einem Vulnerability-Scanner benötigt ein Penetration Test viele manuelle Anpassungen an den zu testenden Prüfling. Ein Vulnerability Scan läuft weitgehend automatisch. Ein bekannter und frei verfügbarer Scanner ist OpenVAS, welcher aus dem Nessus Projekt hervorgegangen ist.

Ausgabe des HTTP Requests durch FireBug

Abbildung 5: Ausgabe des HTTP Requests durch FireBug

Eine wichtige Voraussetzung zum Testen von Online Services ist der sichere Umgang mit einem Crawler. Dieses nützliche Werkzeug folgt den internen Links einer Domäne und wertet den HTTP Request aus. Dabei werden Informationen über Session und Cookie Variablen gesammelt und Formulare geparst. Gerade Sessions, die den Status eines Clients über mehrere Requests serverseitig aufrecht erhalten können, erlauben mit relativ überschaubarem Aufwand bestehende Accounts zu übernehmen. Leicht zu erratende Session ID’s gestatten einem Angreifer unter Umständen sogenanntes Session Riding oder Session Hijacking.

Mit einem Proxy wie WebScrab oder WireShark können Parametermanipulationen auf bequeme Weise durchgeführt werden. Das Open Web Application Security Projekt (OWSAP) stellt sowohl eine umfangreiche Ansammlung an Werkzeugen als auch Informationen zur Verfügung.

Qualitätsbewertung des Sicherheitsmodells

Eine optimale Bewertung über Sicherheit ergibt sich aus einer Mischung von White Box und Black Box Testing – dem sogenannten Grey Box Testing, das vielmals für Penetration Test herangezogen wird. Bereits eine einfache Checkliste erlaubt eine Qualifizierte Aussage über die Güteklasse des Sicherheitsmodelles. Wichtige Punkte sind dabei:

  • SSL Verbindung innerhalb der gesamten Domäne, dies verhindert das Auslesen kritischer Informationen aus TCP Paketen.
  • Passwörter werden nicht im Klartext gespeichert und durch Salt und Pepper verschleiert, dies verhindert Rainbow Table Attacken.
  • Keine versteckten Formularfelder um Informationen weiter zu reichen
  • Keine vertraulichen Daten in Cookies speichern
  • Cookies haben die gleiche Lebenszeit wie Sessions
  • Benutzereingaben werden über den Server validiert
  • generierte Session ID’s müssen schwer vorhersagbar sein
  • Sessions haben einen Timeout, üblicherweise 2 Stunden bei kritischen Anwendungen wie Onlinebanking deutlich kürzer
  • Session ID’s gehören nicht als Parameter in die URI, sondern werden in Cookies gespeichert

Ein weiterer Schritt besteht im Erzeugen der Graphen, deren Knoten die erreichbaren URL’s einer Domäne für alle Benutzerrollen sind. Solche Graphen können mit einfachen Webcrawlern beziehungsweise Agenten generiert werden. Diese Knoten werden mit Zusatzinformationen angereichert, die zur weiteren Analyse heranzuziehen sind. Knoten, die Formulare enthalten sind von besonderem Interesse. Dabei sind auf zwei Dinge zu achten. Die Variablen, beziehungsweise Formular Parameter müssen validiert werden und die Übertragung hat per SSL zu erfolgen. Daraus ergibt sich ein Modell, mit dem bestimmt werden kann welche Inhalte eine Benutzergruppe aufrufen kann. Enterprise Applikationen, welche RESTful Services unterstützen können über diese Methodik besonders gut getestet werden.

Resümee

Grundsätzlich existieren für Cloud Lösungen sehr ausgereifte Sicherheitsstandards, sofern diese auch durch die Entwickler mit berücksichtigt werden. Problematisch ist der Umgang mit den Daten der Kunden eines Cloud Providers. Unabhängige Prüfinstitute könnten diese Bedenken über Datenschutz durch Zertifizierungen ausräumen, dazu wäre eine transparente Vorgehensweise notwendig. Selbst wenn Provider nur die Besten Absichten hegen, besteht die Gefahr von nationalen Regierungen gezwungen zu werden Zugang zu Kundendaten zu gewähren. Das Risiko der Industriespionage ist ein erhebliches Argument gegen die Cloud. Auch wenn Amerika durch Edward Snowden gerade in den Mittelpunkt des öffentlichen Interesses gerückt ist, kann man davon ausgehen, dass auch andere Staaten Technologien besitzen die jenen der NSA ebenbürtig sind. In Europa haben die Aktivitäten der amerikanischen Regierung eine sehr hohe Gewichtung, da viele Unternehmen amerikanische Softwareprodukte verwenden. Die angeführten Gründe sind für viele europäische Unternehmen die Argumentation beispielsweise ein Buchhaltungsprogramm nicht als Cloud Service einzukaufen, sondern eine eigens gehostet Lösung zu bevorzugen. Auch wenn auf den ersten Blick viele Argumente eher pessimistisch klingen mögen, wird sich auch zukünftig die Cloud weiter im Unternehmenseinsatz durchsetzen. Die damit verbundene Flexibilität und wirtschaftlichen Vorteile überwiegen. Die Problematik des Datenschutzes kann durch bereits vorhandene und etablierte Standards gelöst werden, die in aller Wahrscheinlichkeit durch unabhängige Prüfinstitutionen kontrolliert werden. Es kann stark davon ausgegangen werden, dass sich in den nächsten Jahren ein neues Zertifikat für Datenschutz etablieren wird. Die Qualität eines solchen Siegels lässt sich schnell anhand der Transparenz zum getroffenen Urteil bewerten. So wird sich in der Zukunft zeigen ob eine solche Institution eine ähnliche Effizienz wie ein no spy Abkommen erreichen kann. Nicht umsonst ist Datensparsamkeit und Datenvermeidung ein Thema, dessen sich sogar Martin Fowler angenommen hat. Auch Josef Weizenbaum, ein wichtiger Gesellschaftkritiker der in diesem Zusammenhang nicht unerwähnt bleiben darf, mahnt in vielen seiner Bücher3 zum sorgsamen Umgang mit der Information Technologie.

Resources

[1] Forschungsfelder zur Verarbeitung großer Datenmengen: BigData, Information Search and Retrival.
[2] RICHTLINIE 2006/24/EG DES EUROPÄISCHEN PARLAMENTS UND DES RATES vom 15. März 2006
[3] D. Catteddu and G. Hogben, “Cloud Computing: Benefits, Risks and Recommendations for Information Security,” ENISA, 2009; www.enisa.europa.eu/act/rm/ files/deliverables/cloud-computing-risk-assessment/ at_download/fullReport
[4] Takabi, H.; Joshi, J.B.D.; Gail-Joon Ahn, “Security and Privacy Challenges in Cloud Computing Environments,” Security & Privacy, IEEE , vol.8, no.6, pp.24,31, Nov.-Dec. 2010