We all know that vulnerabilities in web pages are quite common these days. These vulnerabilities range from SQL injections, XSS vulnerabilities, CSRF, and so on.
In this article, the first in a two-part series, we’ll provide basic examples of the most common vulnerabilities you’ll find in web pages, including and especially WordPress.
In the second article, to come in a few weeks, we will provide specific action steps you can take to protect yourself from these vulnerabilities.
The denial of service happens for various reasons.
We won’t describe anything like attackers trying to DoS a specific web site with a botnet of compromised computers. Rather, we’ll describe how a DoS vulnerability can happen when writing a code.
Usually we have to make a logical mistake to create a DoS scenario in our web application. Let’s present such a scenario with a little PHP code.
The code below is a PHP sample code that contains a logical error that can be exploited to cause a denial of service.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
In the above code, we’re first checking whether the file parameter exists. If yes, we’re reading the value stored in the file parameter, otherwise we’re closing the application with an error message that says that we didn’t enter the file parameter. Thus, we have to provide the file parameter in order to continue execution of the application.
After that, we’re reading the value stored in the file parameter and checking whether the file exists. If it doesn’t, we’re again closing the application with an error message about a non-existent file. But if a file does exist, we’re including it into the current application execution. From the above code it’s not instantly evident that the code contains a vulnerability that can result in a denial of service.
Let’s say that we saved the above code as index.php and we’re supplying a value of “testing.php” in a file parameter. In such a scenario everything works fine as long as the testing.php file exists and does some work.
But what happens if we provide index.php as a value for the file parameter? In such a case, the index.php file is including itself into the current execution, and this happens infinitely, resulting in a denial of service.
By default, the operating system allocates just so much memory to each application, and if that application wants more memory it is usually forcibly closed by the operating system. This is exactly what happens in this case. When the index.php allocates as much memory as permitted, the operating system forcibly closes it.
Let’s also present a request that we would have to send to the above application to force a DoS. Such a request is presented below:
1 |
|
SQL injection vulnerability is still quite common these days even though it’s been present for over ten years.
SQL injection vulnerability happens when the application isn’t checking the input values for special characters and encapsulating them, and uses the inputted value in the SQL query.
An example of such an application can be seen below:
$show
= 1;
if
(!
empty
(
$_GET
[
'username'
])
and
!
empty
(
$_GET
[
'password'
])) {
$user
=
$_GET
[
'username'
];
$pass
=
$_GET
[
'password'
];
mysql_connect(
"localhost"
,
"admin"
,
"admin"
);
mysql_select_db(
"db"
);
$result
= mysql_query(
"SELECT * FROM users WHERE username='"
.
$user
."' \
AND password=
'".$pass."'
;");
$row
= mysql_fetch_row(
$result
);
if
(
$row
) {
echo
"Welcome user: "
.
$user
;
$show
= 0;
}
}
?>
if
(
$show
) { ?>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
|
We can see that we’re checking whether the parameters username and passwordexist and have a correspondent value. If they have, we’re reading the values into the $user and $pass variables. Afterwards we’re connecting to the SQL database on localhost:3306 with a username admin and password admin and selecting the database db. Then we’re constructing an SQL query sentence in which we’re including the exact values from the username and password inputted values without checking it for special characters.
But we should do that, because the above code is vulnerable to SQL injections, because we’re not encapsulating the username and password inputted values. Imagine that we enter a value ‘ OR 1=1–‘ into both the username and passwordfield. After that the constructed SQL query will be as follows:
1 |
|
This effectively selects all users from the table users because of the OR directive we’ve passed to the vulnerable application. The above SQL query is always evaluated to true and we don’t need to enter the right username and password, which would login us into the application. Instead we can enter special input values to break the logic behind the application and login nevertheless.
The cross-site request forgery vulnerability is present when we can plant a request to the user, which is then sent to the targeted web site in his/her name. The request then executes certain action on the target web site in the user’s name. There are two questions we need to ask ourselves:
The answer to the first question is simple. We can plant a request to the user in various ways through which the end goal is the same: the user’s browser has to send the request to the target web site on one way or another.
We can plant the request to the user on one of the following ways:
We can see that there are various ways to plant a request to the user’s browser, which must execute the request. But this is only half of the story; we still need to talk about what kind of request we can embed into the web page. The requested action can really be anything we like, but the targeted web page must support that action and execute accordingly.
Let’s say that we programmed the web page presented below:
1 2 3 4 5 |
|
When the user visits this web page, a new request will be made requesting the index.php resource on the web page “http://www.anything.com” with parameters id=1000 and action=up.
Now, if that web page doesn’t have the resource index.php the request will fail. But if the index.php is present, but doesn’t use the parameters id and action, the request will again fail. This means that we need to know about the files present on the targeted web page as well as the parameters that the web page uses to do some action.
This way we could alter the results of the survey, where we would make a request that would vote for the first candidate of the survey instead of the other (which might be more popular). After that we would need to attract users to our page, so the voting requests will be sent to the survey as well.
But this is just a tip of the iceberg; imagine what we could do if we could send requests that would add another administrator user to some database, delete all the usernames, or even send arbitrary emails to contacts in users’ mailbox signed by that user, etc.
We’ve looked at the most common vulnerabilities present in web applications today. These vulnerabilities are: Denial of service, SQL injection, Cross-site Request Forgery and Cross-site Scripting.
The goal of this post is to provide an understanding of each vulnerability, and in the next post we will give you specific tips and action items you and your hosting provider can take to protect yourself from these vulnerabilities.
Copyright © 2020 All rights reserved
Comments (0)
eyojeyorej
Your comment is awaiting moderation
eznxunigzote
Your comment is awaiting moderation
iyetigotube
Your comment is awaiting moderation
uwukegoxoxexi
Your comment is awaiting moderation
bimosuwesol
Your comment is awaiting moderation
awumotoleyata
Your comment is awaiting moderation
aitoxax
Your comment is awaiting moderation
ujohakalu
Your comment is awaiting moderation
iyawexusofex
Your comment is awaiting moderation
isezilonni
Your comment is awaiting moderation
ideguwugum
Your comment is awaiting moderation
ebecehu
Your comment is awaiting moderation
agaoqora
Your comment is awaiting moderation
adjafen
Your comment is awaiting moderation
uyorevame
Your comment is awaiting moderation
olizeloi
Your comment is awaiting moderation
ikeqaqiqafzu
Your comment is awaiting moderation
ebaqtorikoog
Your comment is awaiting moderation
ococebdujoqy
Your comment is awaiting moderation
isadizay
Your comment is awaiting moderation
olanjivotayi
Your comment is awaiting moderation
eisayave
Your comment is awaiting moderation
wixoezeic
Your comment is awaiting moderation
obukoraj
Your comment is awaiting moderation
Cymnignip
Your comment is awaiting moderation
masturbaza
Your comment is awaiting moderation
vulpyx
Your comment is awaiting moderation
Dadon
Your comment is awaiting moderation
joycasinoofficial
Your comment is awaiting moderation
CharlesPoels
Your comment is awaiting moderation
irongamers
Your comment is awaiting moderation
lullabies
Your comment is awaiting moderation
Degeguime
Your comment is awaiting moderation
MichaelSmild
Your comment is awaiting moderation
GregoryMug
Your comment is awaiting moderation
avenue17
Your comment is awaiting moderation
novopet
Your comment is awaiting moderation
continent telecom
Your comment is awaiting moderation
european sailing
Your comment is awaiting moderation
virtual local numbers
Your comment is awaiting moderation
JesseNal
Your comment is awaiting moderation
avenue17
Your comment is awaiting moderation
Stevennug
Your comment is awaiting moderation
gwKelMOIEZSoJ
Your comment is awaiting moderation
gwKelMOIEZSoJ
Your comment is awaiting moderation
fKcJevFRNjwIH
Your comment is awaiting moderation
fKcJevFRNjwIH
Your comment is awaiting moderation
OykiLWzZu
Your comment is awaiting moderation
dWnQteiUZPkFEbaK
Your comment is awaiting moderation
dbhPkaCImsNytq
Your comment is awaiting moderation
LxFoRGUAJl
Your comment is awaiting moderation
AlvinTug
Your comment is awaiting moderation