.+:::::::::::::::::::::::::::::::::::::::::/
.//`+++++++++++++++++++++++++++++++++++++// s
-+/.h+..................................-os s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h/ ss s
-+/.h+ ss s
-++-yo////////////////////////////////////y`s
-+o-:--------------------------::::-:://:---s
-+/ :-.: +:oo- s
-+/```````````````````````````````````:-````s
./o//////////+o:::::::::::::::::s+/////////::
``://////////+s:::::::::::::::::y+/////////:.
s .::::/osso::::. .+
`.y +yyyyhNNNmyyyy+ .+
`:h:::::/+:::::::::::::+:///////////////////+--------------------
.o s s::::::::::::s.+ - +
-/y .o s ::::::::::::oss+::.+
`-y .o y `+//: .+
`.+/y/::/+:::::::::::::+:::::::::::::::::++:.
`////////////////////////////////////:/.
Cross-Site Shredder
What happens when the characters of the code are interpreted incorrectly will be shown in the following example. This is an actual security vulnerability in terms of IT security. However, in the context of this work, my intention is not to show that 20-year-old net.art is full of vulnerabilities, but rather what artistic potential lies within them.
To understand the underlying concepts we need to travel back in time a few years.
In the third millennium B.C., cultures in the region of the Fertile Crescent, now Syria, developed what is known as cuneiform writing. The signs were used primarily to organize goods, administration and logistics. For example, one unit of grain was represented by a grain symbol. Even then there were algorithm-like methods for calculating the goods. The cuneiform script was part of the code of these lists and programs printed in clay. With their help, people traded and tried to order and structure society. Against this background, today's computer-controlled world seems like a form of order that has been sharpened to the point of absurdity, and with which people have been trying to gain control over their lives and the environment for thousands of years.
Shortly thereafter, the first hieroglyphs developed in ancient Egypt. Here, too, the partly abstracted but still very pictorial signs were directly linked to meaning. A picture of a fish originally stood for a fish, a duck for a duck, and so on. But little by little, the ever-growing universe of signs proved impractical. If everything in the world is also a sign, the question arises as to the meaning of this endlessly growing system of signs. In addition, there are abstract concepts (how to draw "nothing"?) that are difficult or impossible to represent, which nevertheless had to be agreed upon. Therefore, in the course of time, the hieroglyphic system evolved. The symbols got another meaning as phonetic symbols with the Rebus principle. Rebus is a kind of picture riddle, where the sign gets another meaning. The ancient Egyptian word for catfish is na, the word for chisel is mer. A picture of a catfish and a chisel receives pronounced now the new meaning, the name of the Pharaoh Narmer. At the beginning of this development, the principle was used to write the names of the gods and kings and make immortal the sound of their names, for ever written in the stone of the pyramids.
Later, many new signs were added, the images became more abstract and developed their written meaning. During this development, however, there was a problem. How to read the signs and how to interpret them? Is the sound meant, or the symbol? To answer these questions, people developed a special character, also called a determiner. This should indicate how exactly the following character is to be read. If a picture of a duck is preceded by a determinative, the picture is to be read symbolically, thus actually referencing a duck. Without a determiner, the sound is meant, which is pronounced duck, but in combination with other sounds results in a new word and thus a different meaning. These determinatives also exist in the Chinese character system, because there, too, a character can have several meanings.
When processing code in the computer system, it is also important to define exactly which character is to be interpreted and how. Even a single misunderstood character can lead to the reinterpretation of the entire code.
For example, when a browser displays a web page, many different characters must be read, processed, and correctly interpreted. This is done by a parser. A parser is a program that uses structural characters to break down an input into individual parts that are then available in the correct format for further processing.
For example, the parser of a browser must look for <, because it is a character that announces an HTML tag. Then the parser must look for the >, which closes the tag. Everything in between is inside the tag and belongs to the HTML code. Everything between the closing > and the next opening < is not HTML code but text to be displayed on the interface.
<html> simple text </html>
The separation of code and data is therefore elementary. If a computer program reads in source code to process and execute it, it must be clear what belongs to the code and what is to be interpreted as data. A hack occurs at the point where the two worlds of characters mix.
In order to separate between code and data in the source code of a program, certain special characters are needed to mark this separation. This is different for various programming languages and data types (in the case of HTML code just shown, it is < and >), but in many languages simple text to be displayed on the screen, for example, is enclosed in quotation marks (" and ').
Among them is JavaScript, a programming language found on almost every website today that allows content to be dynamically reloaded or animated and other visual effects to be created. The first quotation mark signals, "From here on is not program code, but literal text." The second quotation mark closes the string.
The best way to make it visible is with syntax highlighting in the code edit.
But now the question arises how to interpret a text which itself contains one or more quotation marks. If the program encounters a quotation mark in the text, it assumes that the string has ended. In reality, however, it goes further, which leads to the fact that everything in subsequent text is again tried to be processed as code.
Here the text, i.e. the data, and the program code have been mixed. As a rule, a program would crash and issue an error message, since text usually does not correspond to the syntax and commands of the code and therefore cannot be processed. However, if text can be injected in such a way that a program accepts it as valid code, the execution and flow of the program can be changed and redirected.
The problem of quotation marks being interpreted in two ways could be solved by the principle of determinatives, which has already been discussed in the example of hieroglyphics. Another prefixed character would invalidate the special role of the quotation mark. In connection with programming languages one speaks of escaping. Certain special characters are used to assign a new role to the characters immediately following them. However, this can quickly lead to high complexity if exactly these special characters are to be treated as literal text again. Then an escape character must be escaped and so on. And high complexity often leads to new possibilities to mix code and data.
In the browser, two syntactically different languages are mixed with HTML and JavaScript. A parser must therefore not only read the < and > characters correctly, but also recognize when it is JavaScript and then pay attention to " and '. A simple example code could look like this:
<html>
<body>
<p>simple Text</p>
<script>
var JavaScript = 'Just text';
if(JavaScript == "Just text"){
console.log("This is just simple text");
}
</script>
</body>
</html>
What can be done with JavaScript is shown here more in detail, using the example of oss.jodi.org
So how can the mechanisms already presented here be used for hacking?
The goal is to inject your own JavaScript into the already existing code of a website.
But for this, gaps must first be found that allow the infiltration.
Hacking & Security books say that the injection of JavaScript code, also known as Cross-Site scripting (XSS), is an extension of "HTML injection".
This is often found in forms where user input is processed and the result is displayed back on the web page.
Since most web applications interact with their users in one way or another, hacking must look for a suitable way to inject code into web pages.
A very creative example of this has been presented by !Mediengruppe Bitnik.
Their book is entitled: <script>alert("!Mediengruppe Bitnik");</script>
The alert(); command is a common way to test XSS in IT security, as a clearly visible box pops up that can only be closed by clicking OK. This means that if the XSS has indeed been successfully injected and executed, it cannot be overlooked and proves that the website has a vulnerability through which malicious code can get in.
The challenge hackers face when infiltrating existing contexts is to find a vulnerability through which the code can be infiltrated in the first place.
The more creative the approach, the higher the probability of actually finding a gap.
Usually, input forms and search bars are used because they are the places where users interact with a page.
Web pages that do not offer any interaction are therefore not exploitable could be an obvious conclusion.
However, if the title of a book is also executable code, completely new injection possibilities arise.
Here, the website operators inject the code (the art) themselves into their site, for example by writing about the new work of !Mediengruppe Bitnik in their blog,
or by offering the book for sale in their online store.
They literally incorporate the title (the code) into their site, and users suddenly see the alert box that blocks the actual content.
The art is made to perform in the context of the code.
Even without direct interaction with a web page,
art could thus be infiltrated into the code context and presumably cause some irritation among the visitors of the affected pages.
This principle of injecting characters will now be illustrated using a concrete example. For this purpose, we will examine another work of net.art that has just such an XSS vulnerability, which makes the underlying principles easy to experience. The failure to properly separate code and data by mixing the quotation marks is what enables the potential for hacking in this example.
As already shown by Jodi's collapsed symbol worlds, the net.artists at the end of the nineties not only investigated the code of the Word Wide Web that was just emerging, but above all asked themselves how we perceive the surfaces of the web pages. The artistic material was the code and the behavior of the Internet itself, with all its possibilities. After the first layer change from the web surface to the code behind it, another reflection on the medium suggests itself. How can the browser itself be used for net.art? This leads to the question of what a browser actually is and whether it is possible to interpret the code of web pages in a different, artistic way.
Some artists developed so-called art browsers in response. One example of the art browser genre, called Riot, was programmed by Mark Napier in 1999 as a continuation of its predecessor Shredder. Shredder advertises an "alternative browser experience," although it is not a stand-alone piece of software, but a website that is accessed through the user's already installed browser. Shredder and Riot simulate a browser by placing an input field at the top of the page that allows the user to enter a URL of another website. The web page is then retrieved and rotated through the shredder resulting in a completely fragmented appearance in the browser window. The artist thereby challenges our usual perception of the design of the World Wide Web and breaks with our ideas of how a page should be displayed. Fragments of HTML source code and parts of the HTTP protocol also appear on the page, which additionally raises the question which parts of the code and which data are interpreted how - both by us and by the program.
Unfortunately, I can't post a detailed writeup for the actual hack here for the following reason:
Thanks for your interest in my net.art. I'm happy to hear that you're exploring the potential of this type of artwork.
As an artist, I'm intrigued by your idea of reversing the artwork's intention - in a sense you're "un-hacking" the artwork.
But as a practical website owner I have to ask that you please don't publish this hack. Most of the people on the internet are not pioneering, forward thinking artists that are intrigued by new ideas. Most of the people on the internet are looking for ways to exploit web traffic for profit. I've had to shut down my site in the past due to exploits that redirected traffic to spam sites. What sounds like an intriguing idea to artists is a source of money to spammers, and they can and do exploit these openings, ultimately to the destruction of the artwork.
Potatoland is currently blacklisted by Google because it is associated with spamming activity, and I have found no way to get through to a human at Google to explain that it's an artwork.
So digital artists, in our excitement to hack the system, paved the way for abuses that ultimately limit or ruin the artwork we created.
Mark
Therefore, at this point only a video, which shows how my hack could bypass the shredder and both web pages and videos are displayed unshredded in the shredder.