A1: 2017 - Injections (Part 2)
In the last article, I assumed that the reader knows how the SQL query language works in detail, as well as the mechanism of the HTTP protocol. But this is usually not the case. And I immediately remembered the story described in one of my favorite books, Robert Brotherton's “Distrusting Minds”. It describes the following experiment. Psychologist Rebecca Lawson asked a group of subjects if they had ever ridden a bicycle in their lives? Most responded affirmatively. She then asked if they knew how a bicycle was made? Affirmative answers were already smaller, but still the vast majority. And then she suggested the following image and asked to add it so that you could ride this bike.
And then the most interesting thing happened - more than half of people could not do it. This deceptively simple task shows that most people simply cannot imagine how a bicycle works. But the most interesting thing is that they do not understand that they do not know this, but begin to understand this only at the moment when they are to demonstrate this knowledge.
C HTTP and SQL happens about the same. 90% of IT professionals wrote SQL queries, at least in laboratories in their schools, people work with HTTP every day as users, and the same IT specialists from time to time set up web servers that actually work with HTTP. But when you have to answer a specific question, a stupor regularly occurs.
An information security analyst should master the technology in detail, knowing the nuances and subtleties. If we don’t know how this or that technology should work, how can we figure out what’s wrong with it?
I mentioned that validation of the input data should occur on the server, but not on the client. Periodically, you can find input forms where individual elements are inactive. And it is assumed that they will become active after certain conditions are met. Or, for example, the username input field has a length of 7 characters, thus limiting the maximum username length. All this is a very bad practice and this is why: elements on the page that have already been received can be arbitrarily edited before being sent, and without any special technical means. In OWASP Mutillidae II, this can be seen in the example “Others”> “Client-side“ security ”Controls”.
Before us is a form, in the fields of which you need to enter a random number, this time it is 2056694312. The “difficulty” here is that the fields have limitations. There is a “Read-only” field, where the number 42 cannot be replaced, there is a too short “Short text box” field, where our number simply does not fit, there is a disabled “Disabled Text Box” field that is inactive, and so on.
In fact, the problem is solved very simply. In the browser (in my case, this is Mozilla Firefox), go to the developer console (F12) and begin to inspect the form elements.
For example, a read only field looks like this:
Delete readonly = ”readonly” and voila: the form is writeable, we can enter our number.
In the next field, our value just does not fit, look at this element:
Here we notice maxlength = ”3 ″. Replace 3 by 333, now we can enter our number without fear that it will not fit.
And this, by the way, is not only about input fields. Similarly, you can change any items, such as check-boxes. Page code looks like this:
It's quite simple here, let's replace the value values with our number, and now it will be sent when the user presses the button.
So, if you know how HTML is arranged, then it will not be difficult for you to correct this form so that you can enter all the necessary data there. Just re-read the section about bike syndrome =)
Injections are not always about databases. By and large, from any form that does not filter incoming data, you can get some additional information. In the example “Application Log Injection”> “DNS Lookup” there is a convenient form for DNS queries:
And indeed, if you enter an address there, for example, google.com, you will get all the necessary information:
However, the vulnerability is that in addition to the first valid command, we can enter something else. For example, specify:
and now the command output is much more interesting:
We executed the query to the DNS server, but besides that, we executed the dir command and looked at what lies in the folder with our site. It will not be difficult, combining different commands, to wander around the hard disk of the web server and look for what is bad.
Next time we will examine some more examples, and also see how you can automate your work.
You can read the blog of the author of the article at this link .
And then the most interesting thing happened - more than half of people could not do it. This deceptively simple task shows that most people simply cannot imagine how a bicycle works. But the most interesting thing is that they do not understand that they do not know this, but begin to understand this only at the moment when they are to demonstrate this knowledge.
C HTTP and SQL happens about the same. 90% of IT professionals wrote SQL queries, at least in laboratories in their schools, people work with HTTP every day as users, and the same IT specialists from time to time set up web servers that actually work with HTTP. But when you have to answer a specific question, a stupor regularly occurs.
An information security analyst should master the technology in detail, knowing the nuances and subtleties. If we don’t know how this or that technology should work, how can we figure out what’s wrong with it?
Also "injection"
I mentioned that validation of the input data should occur on the server, but not on the client. Periodically, you can find input forms where individual elements are inactive. And it is assumed that they will become active after certain conditions are met. Or, for example, the username input field has a length of 7 characters, thus limiting the maximum username length. All this is a very bad practice and this is why: elements on the page that have already been received can be arbitrarily edited before being sent, and without any special technical means. In OWASP Mutillidae II, this can be seen in the example “Others”> “Client-side“ security ”Controls”.
Before us is a form, in the fields of which you need to enter a random number, this time it is 2056694312. The “difficulty” here is that the fields have limitations. There is a “Read-only” field, where the number 42 cannot be replaced, there is a too short “Short text box” field, where our number simply does not fit, there is a disabled “Disabled Text Box” field that is inactive, and so on.
In fact, the problem is solved very simply. In the browser (in my case, this is Mozilla Firefox), go to the developer console (F12) and begin to inspect the form elements.
For example, a read only field looks like this:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />Delete readonly = ”readonly” and voila: the form is writeable, we can enter our number.
In the next field, our value just does not fit, look at this element:
<input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />Here we notice maxlength = ”3 ″. Replace 3 by 333, now we can enter our number without fear that it will not fit.
And this, by the way, is not only about input fields. Similarly, you can change any items, such as check-boxes. Page code looks like this:
<input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />It's quite simple here, let's replace the value values with our number, and now it will be sent when the user presses the button.
So, if you know how HTML is arranged, then it will not be difficult for you to correct this form so that you can enter all the necessary data there. Just re-read the section about bike syndrome =)
Not just SQL
Injections are not always about databases. By and large, from any form that does not filter incoming data, you can get some additional information. In the example “Application Log Injection”> “DNS Lookup” there is a convenient form for DNS queries:
And indeed, if you enter an address there, for example, google.com, you will get all the necessary information:
However, the vulnerability is that in addition to the first valid command, we can enter something else. For example, specify:
google.com && dirand now the command output is much more interesting:
We executed the query to the DNS server, but besides that, we executed the dir command and looked at what lies in the folder with our site. It will not be difficult, combining different commands, to wander around the hard disk of the web server and look for what is bad.
Next time we will examine some more examples, and also see how you can automate your work.
You can read the blog of the author of the article at this link .