{"id":736,"date":"2016-07-05T18:47:25","date_gmt":"2016-07-05T16:47:25","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=736"},"modified":"2023-06-07T11:57:24","modified_gmt":"2023-06-07T09:57:24","slug":"how-is-xss-still-a-thing","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/07\/05\/how-is-xss-still-a-thing\/","title":{"rendered":"How is XSS still a thing?"},"content":{"rendered":"

Back in 2005, the words \u2018But most of all, samy is my hero\u2019 caused great agitation among MySpace engineers as Samy Kamkar injected a Cross Site Scripting (XSS) worm into the social network. The attack consisted in an infected user, publishing a post in their myspace page showing these words honoring its creator, and of course without any intervention of the user itself.<\/p>\n

In 2016, more than ten years after the best known XSS attack, one might think, that XSS would have been taken care of. However, reality is different, at a time when frameworks rule the world of the Web, developers haven\u2019t found the golden solution to the problem. XSS attacks are still at the order of the day with some big names such as Ebay, Lieferando or WordPress among the victims of recent attacks.In this blog post, we are not going to be the first nor the lasts to give some space to this subject, but as long as this security flaw is part of our Web. Developers and users should have an understanding on the thematic, and the dangers it brings with it. Before getting into details let us get a better idea on the current situation of XSS.<\/p>\n

Not for the faint of heart<\/h2>\n

The name “cross site” is confusing. It’s easy to hear it and think that it involves code on one website attacking code on another website. Like a code battle of some sort. But that’s not what it is. Not to mention its unfortunate “true” acronym. So do not confuse XSS with CSS the one is the big bad security vulnerability, while the other is the nice and good styling language.<\/p>\n

Back in 2007 and the good old days of windows vista, Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec.<\/p>\n

Nowadays, and some windows version later, 52% of web applications are still vulnerable to an XSS attack according to security firm Edgescan. So much to getting it fixed!<\/p>\n

\"From
Common Security Problems in Web Applications<\/figcaption><\/figure>\n

The latest big XSS hole, tracks back to January 2016, when an independant security scientist discovered a vulnerability at Ebay\u2019s website. The attack consisted in injecting malicious code through the URL query parameter, thus enabling the attacker to embed an iframe with a fake login page, to later on pass the data to the attacker’s server. To get more information about this check out this great Blog Post<\/a>.<\/p>\n

So, an old problem with not so new faces, XSS is still giving a headache to developers. But why hasn\u2019t it been fixed? And what are developers doing wrong? To understand that we need to understand XSS itself.<\/p>\n

How does XSS work?<\/h2>\n

If we put it in plain and simple language XSS means: executing arbitrary JavaScript code on the page. Notice the word arbitrary, it means that the code comes from some a different source as the one intended from the webpage\u2019s developer.<\/p>\n

The aim of XSS attacks is to run malicious script code inside the victim\u2019s browser. Therefor the attacker embeds the code in the web application. If somebody runs the application in their browser, the malicious code will be delivered with the application and will be executed. These opens a window to not so nice possibilities such as session hijacking, phishing redirects or Cross Site Request Forgery attacks.<\/p>\n

When talking XSS one can distinguish between three types of attacks.<\/p>\n

    \n
  1. Persistent XSS – or the one that infects anyone that visits the corrupted webpage.<\/li>\n
  2. Reflected XSS – or the one in which the user is tricked into running himself the infected code itself.<\/li>\n
  3. DOM-based XSS – or the one where the vulnerability is in the client-side code rather than the server-side code.<\/li>\n<\/ol>\n

    Persistent XSS<\/h3>\n
    \"Persistent
    Visual representation of persistent XSS<\/figcaption><\/figure>\n

    The persistent (or stored) XSS vulnerability is the most devastating variant of a cross-site scripting flaws. Here the injected code is saved on the server, which means, that the malicious code resides inside the application. One way to achieve this is for example to insert malicious code inside a blog post or comment. These will get persisted into the database, and then passed to every user visiting the page. If the victim access the website the code will be executed in the victim’s browser.<\/p>\n

    A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.<\/p>\n

    Reflected XSS<\/h3>\n

    The non-persistent (or reflected) cross-site scripting vulnerability is the most common type. In contrast to the persistent variant the code is not saved to the application.<\/p>\n

    The vulnerability happens when the data provided by a web client, most commonly in HTTP query parameters (e.g. forms), is used by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request.<\/p>\n

    A classic example is a simple search field: if one searches for a string the search string will typically be redisplayed on the result page and the search text gets transferred via a query parameter in the URL – we are assuming the form work through GET. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will arise. Under these conditions an attacker might insert a script into the query parameter like we see in the picture below. If the user is tricked into sending this request to the server the malicious script will be executed by the Browser.<\/p>\n

    \"Reflected<\/a>
    Reflected XSS<\/figcaption><\/figure>\n

    To execute the malicious code inside the victim’s browser the attacker has to make sure the user clicks on the prepared link. To keep the victim from detecting the script tag attackers normally encode the query parameter with base64 transforming the link, or use a URL shortening service with the same result.<\/p>\n

    Normal Link<\/em>
    \n    www.example.com\/search?q=<\/a><\/span>\u201d><script>alert(\u201cHello victim\u201d)<\/script><\/span><\/p>\n

    Link with base64 encoding<\/em>
    \n    www.example.com\/search?q=<\/a><\/span>4oCdPjxzY3JpcHQ+YWxlcnQo4oCcSGVsbG8gdmljdGlt4oCdKTwvc2NyaXB0Pg0K<\/span><\/p>\n

    So keep your eyes open and don\u2019t trust every link!<\/p>\n

    DOM-based XSS<\/h3>\n

    The third type of Cross-Site Scripting is the DOM based version. To understand this attack we need to start with some previous knowledge.<\/p>\n

    The first XSS vulnerabilities were found in applications that performed data processing on the server side. User input would be sent to the server, and then sent back to the user as part of the web page. Making the XSS attack to come from the server.<\/p>\n

    As the JavaScript code was also processing user input and rendering it in the web page content, a new class of reflected XSS attacks started to appear, the DOM-based XSS. In this kind of attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.<\/p>\n

    In the DOM-based XSS attack, there is no malicious script inserted as part of the page; the only script that is automatically executed during page load is a legitimate part of the page. Because the malicious string is inserted into the page source code, it is parsed as HTML, causing the malicious script to be executed.<\/p>\n

    There is a small difference, but it is important:<\/p>\n

      \n
    • In traditional XSS, the malicious JavaScript is executed when the page is loaded, as part of the response sent by the server.<\/li>\n
    • In DOM-based XSS, the malicious JavaScript is executed at some point after the page has loaded on runtime, as a result of the page’s legitimate JavaScript.<\/li>\n<\/ul>\n

      Why DOM-based XSS matters<\/h4>\n

      With modern web Applications being more and more One-Page Web Apps, an increasing amount of HTML is generated through JavaScript on the client-side rather than by the server.<\/p>\n

      This means that XSS vulnerabilities can be present not only in your website’s server-side code, but also in your website’s client-side JavaScript code. Furthermore, even with completely secure server-side code, the client-side code might still unsafely include user input in a DOM update after the page has loaded. If this happens, the client-side code has enabled an XSS attack through no fault of the server-side code.<\/p>\n

      This vulnerability gets even more complicated as any user input that is \u2018hidden\u2019 from the server can damage the user. A simple example is when the malicious string is contained in a URL’s fragment identifier (anything after the # character). Browsers do not send this part of the URL to servers, so the website has no way of accessing it using server-side code.<\/p>\n

      This situation is not limited to fragment identifiers. Other user input that is invisible to the server includes new HTML5 features like LocalStorage and IndexedDB.<\/p>\n

      Now a look at a simple example:  Let’s imagine we have a simple app that personally greets the logged in user.<\/p>\n

      \"A
      welcome.com saying ‘Hi’<\/figcaption><\/figure>\n

      The value of the variable \u2018name\u2019 is extracted from the URL by client-side JavaScript.<\/p>\n

      \"Code
      The code for displaying the name is hard-coded into the web page.<\/figcaption><\/figure>\n

      The script uses document.write to inject the extracted username to the DOM and render it in the Browser. This is done in such a manner that for  attacker is able to manipulate the link and replace the name of the user with a script tag like welcome.com?name=<script>alert(\u201cHello Victim\u201d)<\/script>.<\/p>\n

      As already mentioned, what makes this kind of attacks so special, is that the server doesn\u2019t notice or have to do anything with the intrusion itself.<\/p>\n

      As said before, the problem has been the same for old and new web applications. But what are developers doing wrong? What can one do against this kind of attacks in order to protect users and servers intrusion?<\/p>\n

      Methods of preventing XSS<\/h2>\n

      So let\u2019s go back to basics, keeping in mind that an XSS attack is a type of code injection. In order to prevent this type of code injection, secure input handling is needed. For a web developer, there are two fundamentally different ways of performing secure input handling:<\/p>\n

        \n
      • Encoding<\/span>: escapes the user input so that the browser interprets it only as data, not as code<\/li>\n
      • Validation<\/span>: filters the user input so that the browser interprets it as code without malicious commands<\/li>\n<\/ul>\n

        While these are fundamentally different methods of preventing XSS, they share several common architectural parts of an application that are important to understand when using either of them:<\/p>\n

        Context<\/em>
        \n<\/span>Input validation has to be performed differently depending on where in a page the user input is inserted. The expected data and its type have to be verified and proofed accordingly.<\/p>\n

        There are many contexts in a web page where user input might be inserted. For each of these, specific rules must be followed so that the user input cannot break out of its context and be interpreted as malicious code.<\/p>\n\n\n\n\n\n\n\n\n
        Context<\/span><\/td>\nExample code<\/span><\/td>\n<\/tr>\n
        HTML element content<\/td>\n<div>userInput<\/div><\/td>\n<\/tr>\n
        HTML attribute value<\/td>\n<input value=”userInput”><\/td>\n<\/tr>\n
        URL query value<\/td>\nhttp:\/\/example.com\/?parameter=userInput<\/td>\n<\/tr>\n
        CSS value<\/td>\ncolor: userInput<\/td>\n<\/tr>\n
        JavaScript value<\/td>\nvar name = “userInput”;<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        An example of how to take context into consideration, would be as following. If at some point a website inserts user input directly into an HTML attribute, an attacker would be able to inject a malicious script by beginning the input with a quotation mark.<\/p>\n

        For example, if at some point a website inserts user input directly into an HTML attribute, an attacker would be able to inject a malicious script by beginning his input with a quotation mark, as shown below:<\/p>\n\n\n\n\n\n
        Application code<\/span><\/td>\n<input value=”userInput”><\/td>\n<\/tr>\n
        Malicious string<\/span><\/td>\n“><script>…<\/script><input value=”<\/td>\n<\/tr>\n
        Resulting code<\/span><\/td>\n<input value=””><script>…<\/script><input value=””><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        This could be prevented by removing all quotation marks in the user input, but this would only work in this context.<\/p>\n

        Inbound\/outbound
        \n<\/span><\/em>Input validation should be performed either when a website receives the input (inbound) or when the input leaves the page to the server (outbound).<\/p>\n

        It might seem that XSS can be prevented by encoding or validating all user input as soon as your website receives it. This way, any malicious strings should already have been neutralized whenever they are included in a page, and the scripts generating HTML will not have to concern themselves with secure input handling.<\/p>\n

        However, because of the uncertainty of in which context will user input used, it can be able be used in multiple contexts. And it is never a good idea to trust our own UI. Attackers will find ways to send or manipulate data in the page. But in general, it is important to consider outbound input handling as our primary line of defence against XSS.<\/span><\/p>\n

        Client\/server
        \n<\/span><\/em>Secure input handling can be performed either on the client-side or on the server-side, both of which are needed under different circumstances. But at best, is performing validation at both ends.<\/p>\n

          \n
        1. In order to protect against traditional XSS, secure input handling must be performed in server-side code. This is done using any language supported by the server.<\/li>\n
        2. In order to protect against DOM-based XSS where the server never receives the malicious string, secure input handling must be performed in client-side code. This is done using JavaScript.<\/li>\n<\/ol>\n

          How to perform encoding and validation?<\/strong>
          \nWe will continue by explaining how the two types of secure input handling (encoding and validation) are actually performed.<\/p>\n

          Encoding<\/h3>\n

          Encoding is the process of escaping user input so that the browser interprets it only as data, not as code. The most recognizable type of encoding in web development is HTML escaping, which converts characters like < and > into their HTML entities such as  &lt; and &gt;, respectively. When all characters in the input were escaped, the browser will not parse any of the user input as HTML.<\/p>\n

          Encoding in client-side and server-side code
          \n<\/span><\/em>When performing encoding in your client-side code, the language used is always JavaScript, which has built-in functions that encode data for different contexts.<\/p>\n

          When performing encoding in your server-side code, you rely on the functions available in your server-side language or framework. The best thing to do in this cases is to go to your nerdy buddy and ask him for any recommendations on what encoding function to use and if there are any tested and know framework for this task.<\/p>\n

          Limitations of encoding
          \n<\/span><\/em>Even with encoding, it will be possible to input malicious strings into some contexts. A notable example of this is when user input is used to provide URLs. In situations like these, encoding has to be complemented with validation.<\/p>\n

          Validation<\/h3>\n

          Validation is the act of filtering user input so that all malicious parts of it are removed, without necessarily removing all code in it. One of the most recognizable types of validation in web development is allowing some HTML elements (such as <em> and<strong>) but disallowing others (such as <script>).<\/p>\n

          There are two main characteristics of validation that differ between implementations<\/p>\n

          1. Classification strategy
          \n<\/span><\/em><\/span>User input can be classified using either blacklisting or whitelisting.<\/p>\n

          Blacklisting<\/span><\/strong><\/em>, Instinctively, it seems reasonable to perform validation by defining a forbidden pattern that should not appear in user input. If a string matches this pattern, it is then marked as invalid.<\/p>\n

            \n
          • Complexity and Staleness<\/span>, Accurately describing the set of all possible malicious strings is usually a very complex task and even if a perfect blacklist were developed, it would fail if a new feature allowing malicious use were added to the browser.<\/li>\n<\/ul>\n

            One should aggregate security measures in order to cover as much ground as possible. But because of these drawbacks, blacklisting as a classification strategy is strongly discouraged. On the other hand is Whitelisting is usually a much safer approach.<\/p>\n

            Whitelisting<\/span><\/strong><\/em>, is essentially the opposite of blacklisting: instead of defining a forbidden pattern, a whitelist approach defines an allowed pattern and marks input as invalid if it does not match this pattern.<\/p>\n

              \n
            • Simplicity and Longevity<\/span><\/em>, Accurately describing a set of safe strings is generally much easier than identifying the set of all malicious strings, and unlike a blacklist, a whitelist will generally not become obsolete when a new feature is added to the browser.<\/li>\n<\/ul>\n

              2. Validation outcome
              \n<\/span><\/em><\/span>User input identified as malicious can either be rejected or sanitised.<\/p>\n

              Rejection<\/span><\/strong>, The input is simply rejected, preventing it from being used elsewhere in the website.<\/p>\n

              Sanitisation<\/span><\/strong>, All invalid parts of the input are removed, and the remaining input is used normally by the website.<\/p>\n

              Of these two, rejection is the simplest approach to implement. That being said, sanitisation can be more useful since it allows a broader range of input from the user. Extremely important for sanitation is the use of well-tested libraries and frameworks whenever possible.<\/p>\n

              So when to do what?<\/h2>\n

              Encoding should be your first line of defense against XSS, because its very purpose is to neutralize data so that it cannot be interpreted as code. In some cases, encoding needs to be complemented with validation, as explained earlier. This encoding and validation should be outbound, because only when the input is included in a page do you know which context to encode and validate for.<\/p>\n

              As a second line of defense, you should use inbound validation to sanitize or reject data that is clearly invalid. While this cannot by itself provide full security, it is a useful precaution if at any point outbound encoding and validation is improperly performed due to mistakes or errors.<\/p>\n

              If these two lines of defense are used consistently, your website will be protected from XSS attacks. However, due to the complexity of creating and maintaining an entire website, achieving full protection using only secure input handling can be difficult. As a third line of defense, you should also make use of other security measures such as the Content Security Policy (CSP).<\/p>\n

              To wrap things up<\/h2>\n

              XSS, not to be confused with CSS, is a code injection attack made possible through bad handling of user input. A successful XSS attack allows an attacker to execute malicious JavaScript in a victim’s browser, and compromises the security of both the website and its users.<\/p>\n

              There are three types of XSS attacks:<\/p>\n

                \n
              • Persistent XSS: the malicious input comes from the website’s database.<\/li>\n
              • Reflected XSS: the malicious input originates from the victim’s request.<\/li>\n
              • DOM-based XSS: the vulnerability runs in the client-side code rather than the server-side code. The server never finds out about it.<\/li>\n<\/ul>\n

                The most important way of preventing XSS attacks is to perform input handling in order to validate and given the case sanitize the input.<\/p>\n

                  \n
                • Secure input handling has to take into account which context of a page the user input is inserted into, this means where is the input to be used.<\/li>\n
                • Encoding should be performed whenever user input is included in a page. And validation of the input has also to be taken into consideration.<\/li>\n
                • Secure input handling has to be performed in both client-side and server-side code.<\/li>\n
                • Use well-tested frameworks for this and regularly check for updates framework.<\/li>\n<\/ul>\n

                  So to conclude, XSS will be around us as long as attackers find a way to get their malicious code to the user or into the system. Make a perfect system in which all holes are close is an extremely complex task if not impossible. But a good start is to make a solid application with a good foundation which implements secure data handling mechanisms.<\/p>\n

                  Hope this guide has given you a little insider view into the topic of XSS. As a developer take into consideration the points related in this post and try to apply them. As a user keep in mind that the web is a big open place and not all links are that good, especially the ones that promise free smilies.<\/p>\n","protected":false},"excerpt":{"rendered":"

                  Back in 2005, the words \u2018But most of all, samy is my hero\u2019 caused great agitation among MySpace engineers as Samy Kamkar injected a Cross Site Scripting (XSS) worm into the social network. The attack consisted in an infected user, publishing a post in their myspace page showing these words honoring its creator, and of […]<\/p>\n","protected":false},"author":29,"featured_media":775,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[26,651],"tags":[39],"ppma_author":[684],"class_list":["post-736","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-secure-systems","category-system-designs","tag-xss"],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2016\/07\/52_s9fTmrNTxuCmSF-BL5Dl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9-1.jpg","jetpack-related-posts":[{"id":10939,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/11\/how-are-vulnerabilities-exploited-to-compromise-a-system\/","url_meta":{"origin":736,"position":0},"title":"How are vulnerabilities exploited to compromise a system?","author":"Joel Beiter","date":"11. September 2020","format":false,"excerpt":"This article is a recap of the \"Live Hack\" presentation, held in the lecture \"Sichere Systeme\" in SS 2020. It will introduce different vulnerabilities like XSS and SQL-Injection and shows how passwords can be cracked under certain circumstances. The last step explains how a SUID binary was exploited to gain\u2026","rel":"","context":"In "Secure Systems"","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":26378,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2024\/07\/25\/secure-code-fast-delivery-the-power-of-devsecops\/","url_meta":{"origin":736,"position":1},"title":"Secure Code, Fast Delivery: The Power of DevSecOps","author":"Furkan Erdogan","date":"25. July 2024","format":false,"excerpt":"In today\u2019s fast-paced digital world, security breaches are more than just a risk; they\u2019re almost a guarantee if you don\u2019t stay ahead. Imagine being able to develop software at lightning speed without compromising on security. Sounds like a dream, right? Welcome to the world of DevSecOps! If you\u2019re curious about\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/grafik.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/grafik.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/grafik.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/grafik.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/grafik.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/grafik.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":718,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/06\/28\/side-channel-attacks\/","url_meta":{"origin":736,"position":2},"title":"Side-channel Attacks","author":"Daniel Grie\u00dfhaber","date":"28. June 2016","format":false,"excerpt":"This post will give you an introduction to Side-channel Attacks by looking at some common vulnerabilities and concrete attacks that try to exploit those. But first: What actually is a Side-channel attack in general? A Side-channel Attack is an attack on a system, most probably a \u201csecure\u201d system, that does\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":11267,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/29\/montagsmaler-multiplayer-online-game-running-on-amazon-web-services\/","url_meta":{"origin":736,"position":3},"title":"Montagsmaler \u2013 Multiplayer online game running on Amazon Web Services","author":"ns107","date":"29. September 2020","format":false,"excerpt":"by Jannik Smidt (js343), Niklas Schildhauer (ns107) and Lucas Cr\u00e4mer (lc028) Project idea Montagsmaler is a multiplayer online game for web browsers. The idea is derived from the classic Pictionary game, where players have to guess what one person is painting. Basically, we have built the digital version of it,\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/09\/Untitled-Diagram.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/09\/Untitled-Diagram.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/09\/Untitled-Diagram.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/09\/Untitled-Diagram.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":3867,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/08\/07\/social-engineering-hacking-the-human-os\/","url_meta":{"origin":736,"position":4},"title":"Social Engineering – Hacking the human OS","author":"Benjamin Kowatsch","date":"7. August 2018","format":false,"excerpt":"Abstract Nowadays, our secure systems are already sophisticated and perform well. In addition, research on subjects such as quantum computers ensures continuous improvement. However, even with a completely secure system, we humans pose the most significant threat. Social engineers prey on this to conduct illegal activities. For early detection and\u2026","rel":"","context":"In "Secure Systems"","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":10442,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/08\/19\/adversarial-attacks\/","url_meta":{"origin":736,"position":5},"title":"The Dark Side of AI – Part 2: Adversarial Attacks","author":"Florian Wintel","date":"19. August 2020","format":false,"excerpt":"Find out how AI may become an attack vector! Could an attacker use your models against your? Also, what\u2019s the worst that could happen? Welcome to the domain of adversarial AI!","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/08\/fgsm_panda_image_preds_1.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/08\/fgsm_panda_image_preds_1.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/08\/fgsm_panda_image_preds_1.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/08\/fgsm_panda_image_preds_1.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/08\/fgsm_panda_image_preds_1.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2020\/08\/fgsm_panda_image_preds_1.png?resize=1400%2C800&ssl=1 4x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":684,"user_id":29,"is_guest":0,"slug":"me083","display_name":"Mario Erazo","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/0073577e41cafa4dfb6d94b3a8fbeb156decdfde755af62c0e40f88b9f9b4348?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/736","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/29"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=736"}],"version-history":[{"count":11,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/736\/revisions"}],"predecessor-version":[{"id":24676,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/736\/revisions\/24676"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media\/775"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=736"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=736"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=736"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=736"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}