Blog Post

Blog
  1. Home
  2. Blog
  3. 3 WordPress Security Vulnerabilities You Should Be Familiar With

3 WordPress Security Vulnerabilities You Should Be Familiar With

  • Admin
  • 2017-09-20 23:13:37
  • 52
  • 30
facebook twitter linkedin google+

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.

1. DoS (Denial of Service)

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

 

if(empty($_GET['file']))

 

die('You didn\'t enter the file parameter.');

 

$file = $_GET['file'];

 

if(!file_exists($file))

 

die('The chosen file does not exist.');

 

include($file);

 

?>

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

GET /index.php?file=index.php HTTP/1.0

2. SQL Injection

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) { ?>

 

 

"#">

 

 

Username: "text" name="username" />

 

Password : "password" name="password" />

 

 

 

 

 

 

 

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

SELECT * FROM users WHERE username='' OR 1=1--'' AND password='' OR 1=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.

3. CSRF (Cross-Site Request Forgery)

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:

  1. How can we plant a request to the user?
  2. What kind of action can we execute on the target web site?

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:

  • In case the target web site is vulnerable and we can temporarily inject some code into it, we need to construct the right URI that we sent to the user, who must click on it. Upon clicking on the URI, the initial request will be sent, but because of the vulnerability a second request will be made to request the action that we specified.
  • In case the target web site is vulnerable and we can permanently inject some code into it, we can simply insert another request into the source code of the web page. When the user visits that specific web page sometimes in the future, our custom request will be executed in the user’s name. This approach doesn’t even need social engineering to work, because all the user has to do is visit the vulnerable web page.
  • We can also construct our own web page, which we have total control over. This is why we can include the code that will do the malicious request in the source code of the web page alone. But in the end the user must still visit that web page, which is why we must send him or her a link to our own web page. When the user visits the web page, the requests embedded into the web page alone will be executed in the user’s name.

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

<body>

 

<img src="http://www.anything.com/index.php?id=1000&action=up"/>

 

body>

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.

Conclusion

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.

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

Get started with us

We are happy to help you for growing your business

Himanshu Softtech is a global IT services company that provides Business Process Outsourcing, Offshore Software and Web design, Digital Marketing and Data Processing, Domain and Hosting.

Important Links

Get in touch

  • +91 8989977272

    Get a free quote

  • 10:00 - 19:00 / IST

    Monday - Saturday
  • 65,Shivaji Nagar, Moti Banglow, Dewas, Madhya Pradesh, 455001, India

Copyright © 2020 All rights reserved

Get an account with HSOFT

Create

Reset your account password

Submit