Welcome come to a lecture dedicated to application protocols in this session we'll examine the Protocols
of the two highest leaders of the OS and model.
Let's start with the presentation layer presentation layer protocols are responsible for encoding decoding
and displaying in applications the data sent by the lower layer protocols.
This is kind of a standard interface between for example an application written in ph p a Web site written
in HSP dot net and data transport protocols
implementation of presentation layer protocols is crucial for the safety of the entire network application.
Let's discuss a few examples.
The first one concerns the i s server.
This is a Microsoft web server.
One of the earlier versions of the server allowed anonymous access to the hard drive of the computer.
The IRS was installed and run on
its records only had to properly encode the request for access to a selected file in a hexadecimal format.
The server rejected the HTP get requests for files to which a Web site user should not have had access.
However if a hexadecimal number which encoded the files directory was given as the get request attribute
the server fulfilled the request one should not be able to browse a web server folder structure.
To prevent this.
The server checked if anyone used a combination of characters double dot for Slashdot.
If someone tried to use this combination the request was blocked.
However the same request encoded as percent see zero percent A.F. was fulfilled.
The problem was that the same thing could be encoded in many ways.
If you try to secure an application with the mechanism checking if an action is hostile with a default
assumption that it's not you'll fight a lost battle.
When you create a line of defense you always have to show ingenuity.
You have to imagine how else the requests can be encoded.
So in the example mentioned all possible ways of encoding a request should be blocked.
But such an approach is simply impractical
the typical problem of presentation layer protocols is the null by injection
many network applications are created in high level programming languages DHP Java Perl s dot net
these languages use environments or frameworks written in another language usually C or C++ in these
languages and the string is marked in a special way in C or C++ the string doesn't have a specified
length the string ends with the null characters or zeros.
This means that everything that comes after is ignored.
Let's look at a few examples.
Suppose that you write a script in HP allowing someone to download files with a data extension we can
do it as it's shown.
This is a simple function allowing us to download a file with the name specified by the user.
The function will work properly if the user executes it in the following way.
H t t p w w w dot server dot com user ph P file my profile Dat that
are what happens if the function is executed in the following way.
H t t p w w w does server dot com user ph P questionmark file equals datt forward slash doubleback forward
slash doubled up forward slash C forward slash password gnome at the end of this command.
We see a null character indicating the end of the string.
In this case the extension that will not automatically be added.
The problem with translating expressions between different platforms and different ways of encoding
means that a function can be executed differently than its creator had intended.
This is a simple and universal example.
It doesn't apply to BHP only
we see a similar function written in Java.
It will be used for reading files this time with the extension D-B
this time to the correct request namely surfer dot com forward slash my page that J S P.
Question mark.
F n equals report that the B can be replaced by the following
server dot com forward slash.
My page done.
James P. questionmark effen equals server logs that Milde that the.
Again the attacker uses the function in the way the creator hasn't thought of.
The problem is that the issue doesn't concern only the specific web application of company x.
This is the issue of the environment or the language in which these applications are created.
This is a very common problem.
That's why many applications are susceptible to no byte injection attacks.
It doesn't mean that the applications are poorly written.
It just means that they're written in this specific environment.
Some environments can be exploited which means that they allow for certain requests to be encoded in
another way than expected.