In Web Development Soup, you will learn important HTML, CSS, JavaScript, and PHP concepts. You will get up-to-date with the recent developments in HTML5 and CSS3 – the tags, selectors, attributes and APIs they offer. You will get acquainted with Foundation and Twitter Bootstrap which are invaluable when it comes to designing user interfaces. In terms of JavaScript, you will build basic knowledge of recent developments such as Angular.js, jQuery, Node.js, new JavaScript APIs and features. In terms of PHP, you will get a head start on WordPress, Laravel, CakePHP and so on.

Throughout the book, besides explaining different possibilities in the programming languages and giving sample codes we will also be building real and functioning applications such as a voice chat with Node.js, a small marketplace with CakePHP, a simple game with JavaScript and Processing.js, two apps where users can take and manage notes, a screenshot-capturing service in which users can enter a URL address and get a screenshot of the website as our server sees it, and more.

Furthermore, some widgets will be built such as a countdown timer which can be reused in your applications, a PHP script which takes an URL address to a WordPress RSS feed and extracts all relevant information for you to use or displays its contents in a table, amongst others.

Check out the book’s accompanying website: http://wds.dimoff.biz.
In it, you can download all code samples from this book and examine them or run them in a browser. Furthermore, you can do the exercises on the website each time you read a chapter and if you manage to complete all exercises and the final exam without mistakes (you can repeat the exercises as much as you like) you can get a special certificate!

In the bottom of the book, you will find your username and password. Use them to access the code samples and the tests.

Some other useful aspects of web development are also examined in the Web Development Soup – such as improving your workflow, securing web applications and optimizing your websites in search engines.

Тhe content of the book will serve you well in establishing a base knowledge of the different aspects of web development and guide you to find out the sphere that you most like and will empower your career.

This book will be periodically updated with new content, as well as the accompanying website. New things will be added at least once every few months.

Web Development Soup is sold in Amazon for $3.49

by

This book will be useful to anyone engaged in, or studying, web development or/and penetration testing as well as those interested in information security and in web security, in particular.

A wide array of vulnerabilities are discussed including code injections, XSS, Clickjacking, CSRF, DoS, Content Spoofing, Information Leakage along with many other flaws related to various parts of web applications – such as authentication flaws. Each chapter discusses a particular vulnerability and most chapters have code samples which show the type of code that’s susceptible to an attack, as well as sections depicting the ways in which the vulnerability may be prevented or mitigated.

Three interactive quizzes are also included with the book which can help you in the learning process and let you know if you have retained the material.

The book is best read by people who have at least some basic knowledge of one or more of the following languages: HTML, JavaScript, PHP, Node.js

Download the Web Vulnerabilities Explained eBook for FREE

by

In this last part of the Website Hacking series, we are going to list 18 common web vulnerabilities and flaws and we are going to briefly provide solutions to them. Some of them are described for the first time in the Website Hacking series and some we have discussed before but in greater depth.

1. Saving all user input

If you are using a framework, for example, a PHP framework, you might be tempted to save all user input to your model or database since it has already been validated and escaped. Let us say that you are using CakePHP and have included a registration form using CakePHP’s Form helper.

The registration view may look something like this:

<?php echo $this->Form->create(“User”);

echo $this->Form->input(“username”,

array(“label” => ‘Username:’)

);

echo $this->Form->input(“password”,

array(“label” => ‘Password:’)

);

echo $this->Form->end(      array(‘class’ => ‘button  medium radius success ‘,        ‘label’ => “Register”        )      );

Now, you might be tempted to save all data from CakePHP’s $this->request->data array/method as is if you do not read the docs carefully or view some of the examples provided there (the live blog site).

public function register() {

if ($this->request->is(“post”)) {
$this->User->create();

if ($this->User->save($this->request->data)) {

$this->Session->setFlash(“Account created. You may log in!”);
$this->redirect(array(
‘controller’ => ‘offers’,
‘action’ => ‘index’
));
}
}}

You just save all data and thank the framework creators. However, there are at least two things you did wrong:

$this->request->data does not contain escaped/sanitized input, just the input from the superglobals.

Firstly, you should use CakePHP’s h() function to prevent people inserting tags in their username: like this h($this->request->data)

However, this is not enough and a wrong approach. If you save all user input in your Model (database) the user can add new input tags directly in his browser and try to guess some columns in your users table for which you have not provided an input in the website’s form.

For example, many CakePHP’s applications have “role” column set to user/admin or something similar (it is used in the docs as well).

The user can just open his Developer Tools, find the registration form or right click and select Inspect Element, click on Edit as HTML and add a new input like this:

<input name=”data[User][role]” type=”text”>

<input name=” [User][role]” type=”text”>

Or whatever the current way for forms to interact with your Models is, guess column names and insert values to them.

One way to solve this is to change your column that defines user’s roles and permissions name to something unpredictable. However, that is not the safest approach you can take.

You can either insert the data into the database manually, which will ensure no extra columns will be saved:

$AddUser = array(‘User’ => array(

‘username’ => h($user[‘User’][‘username’]),

‘password’ => $user[‘User’][‘password’]

));

if ($this->User->save($AddUser)) {

Or alternatively, you could still save all user data but set explicitly the values of columns not found in the form:

public function register() {

  if ($this->request->is(“post”)) {

$this->request->data[‘User’][‘role’] = “user”;

$this->User->create();

if ($this->User->save(h($this->request->data))) {

$this->Session->setFlash(“Account created. You may log in!”);

$this->redirect(array(  ‘controller’ => ‘offers’,  ‘action’ => ‘index’   ));

}

}

}

2. Allowing user access to assets

Many sites work with user input and user data and store this data. Clients can see where their assets are stored, so there is no need for them to guess. For example, a client could see that the images he uploaded were stored in /uploads/{username} because the images he uploaded were loaded to the page from that directory, so if he knows some usernames of different people he could just change the directory name to another user and browse through all of his data without having to brute-force directory names.

The first way to tackle this issue that we discussed before is not enough (adding Options All –Indexes to the .htaccess file).It would prevent users from browsing directories and opening whatever they want but they would still know the directory exists and they can still guess directory names because the server will return a 403 Forbidden (which shows something exists in that path). Furthermore, they could guess file names from some patterns that the file names follow and open them.

Therefore, you need to block access to the files in your uploads directory. If you are storing text files (let us say users can keep notes and view/edit them whenever they want) you could add to your .htaccess the following rule:

RewriteEngine On

RewriteRule ^uploads/.*\.(txt|doc)$ – [F,L,NC]

The F flag would return a 403 Forbidden response, the L flag causes the next rules to stop being processed, and the NC eliminates case-sensitivity.

Figure 1: The page with only directory listing disabled.

Figure 2: The page with only directory listing disabled. You cannot browse directories, but if each user has a notes.txt file, you can easily view user’s notes by knowing only their username.

Figure 3: Trying to access the notes with both directory listing and controlled access to files.

If you use the rewrite rule to disable users from browsing other users notes, your back-end would still be able to access the notes, show them to users or edit them. For example:

<?php

$user = “Cartman”;

$userNotes = file_get_contents(dirname(__FILE__). “/yourSite/uploads/{$user}/notes.txt”);

echo “<p> $userNotes </p>”;

?>

Where the $user variable would come from a session in a real-world application.

3. Running basic WordPress installation

Common mistakes here are not limiting the login attempts on your wp-admin page. This would allow anyone to brute-force your credentials and destroy your blog/site. This becomes even easier because most people create their master username to be ‘admin’ which involves only brute-forcing the password to get full access to the WP website. Another mistake is that the wp-admin login page is left without a form of CAPTCHA or a protection against bots. This combined with no limitation of login attempts equals certain death of your online presence at some point in the future. You could avoid all 3 of these things and also change the default wp-admin path to be something different as well (obfuscation).

4. Relying too much on IP addresses while having weak bot protection

Most ISPs provide dynamic IP addresses, and the IP address you have banned or stored may already be obsolete in less than a day. Furthermore, it is often not very difficult to change your IP address – use a proxy, release it from the router or from the OS, change locations. There are myriad ways to do it. To prevent bots from causing undesired consequences, it would be better to use alternative ways – enhance your CAPTCHAs, add inputs only bots will fill out, require JavaScript/cookies enabled to submit a form, and so on.

5. Improper redirects

Let us say that you have a redirect page or a GET value (for simplicity’s sake) that redirects users to another page of your site or to another website. However, if you forget to disallow redirects to third-party websites or in case you allow those, if you do not create a warning page before redirecting that will tell the user where they are going and that they are leaving the site – users can easily abuse your site by giving links that seem to be pointing to your site but will redirect users to malicious websites.

if (isset($_GET['redirect'])) {
		header("Location: " .  $_GET['redirect']);
	}

If we have something as simple as this, then users can easily get fooled to enter bad sites by following an URL like this:

http://localhost:8079/articles/Website%20Hacking%20Part%20VII/?redirect=http://www.somemalicioussitehere.com

6. Cross Site Request Forgery

If your site allows users to add comments/posts and insert tags such as <img> and load a third-party image, they can provide a link that is not an image but will fool the clients’ browsers (the users that will be reading them) to load the resource and perform an action on a website if they are authenticated in it. For example, if Facebook was sufficed with a couple of GET parameters or a particular URL to follow someone/something on their network, we could have added an image like that:

And if the user is currently logged in he would have followed an arbitrary person. Of course, this would not work in this particular situation.

7. Insecure file handling

A common mistake is to trust that a file does not contain something inappropriate. Code can be disguised as an image, so checking the file extension is not enough. At the very least, the MIME type should also be checked. Also, ASCII / text files should be escaped.

Here is an example of such a vulnerability:

<form action=”” method=”POST” enctype=”multipart/form-data”>

<input type=”file” name=”myTxt”> <br><br>

<input type=”submit” value=”Upload”>

</form>

<script>

$(“form”).on(‘submit’, function() {

if ($(“form input[type=’file’]”).val().split(“.”).pop() === “txt”)

{               return true        }        else {               return false;        }

})

</script>

The vulnerability arises when at some point we display the contents of the .txt file in our page:

if (isset($_FILES[‘myTxt’])) {

echo readfile($_FILES[‘myTxt’][‘tmp_name’]);

}

If the file we submit contains the following code:

<script>

alert(document.cookie);

</script>

Then all user cookies for that website will be shown in an alert.

8. Displaying and trusting HTTP headers

These can be modified by users and can be malicious. For example, if you display the client’s User-Agent header, it might be changed to consist of code which would then be executed in your back-end.

This is also valid for the referrer header, so it should not be used to determine whether the user can access a particular page by itself (for example, checking if the referfer is the login page and assuming the user has logged in successfully since he was redirected to the members area’s index page from the login page).

9. Information disclosure

Your live apps should not be in debug mode. Errors should not be shown.

10. Directory traversal

If you are using some parameter that opens different files on your website based on user input, your back-end should escape special characters such as the . (dot) or / (slash) from the input and preferably use whitelisting.

11. Using HTTP for semi-confidential data

A common flaw is using HTTP for sites that include mechanisms such as registration/login. Even widely used online marketplaces in Bulgaria use simple HTTP (such as http://www.olx.bg ). Using HTTP makes it easy for potential attackers in your network to sniff your traffic and get your credentials with no real efforts. For example, if you login to olx while in a Wi-Fi, you are subject to risk.

13. Sessions can be stolen

Sessions can be stolen, making the attacker login as someone else. There are multiple vectors of defense here – such as checking the IP address, the user agent, and regenerating session, and adding cookies.

14. Be careful which third-party libraries, CDNs and plugins you use

They might be simply outdated, opening a wide variety of security holes, or they might be malicious – giving access to the shady library’s creator to your server.

15. Bots are everywhere

Take care of malicious bots not by banning their IP but by enhancing CAPTCHA, adding hidden form fields that users would not fill, and requiring JavaScript or cookies enabled to submit a form.

16. Use HTTP only cookies

This would reduce the impact of some other attacks – such as XSS

17. Hashing

Hash your passwords and try to avoid md5 or sha-1 algorithms (https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know, http://security.stackexchange.com/questions/33108/why-does-some-popular-software-still-use-md5 ). Use salts to prevent attacks with rainbow tables.

18. XSS

Always escape input unless you really, really trust the source (admin panel). You can either remove tags or display them as entities depending on your needs. | PHP: strip_tags($input, $allowedTags); htmlspecialchars($input, ENT_QUOTES); htmlentities($input); |

19. SQL Injection

Use prepared statements or do not perform a query which is not hardcoded without sanitizing it (PHP: PDO class or sanitize with mysqli_real_escape_string($conn, $str) if using mysqli. Do not use mysql_*).

Conclusion

This was the last part of the Website Hacking series. We have introduced some new vulnerabilities and briefly discussed them and have summarized our points for everything that we have talked about so far.

We hope that now you will feel more confident when deploying your web apps by putting these strategies in use.

To download the code that comes with this article and read it from its original place of publishment, please visit: http://resources.infosecinstitute.com/website-hacking-part-vii-common-web-vulnerabilities-brief-solutions/

by

To install Laravel first you need to download and set up Composer. If you are using Windows you can grab the .exe file and run it which will set Composer up automatically.

For other operating systems, you should follow the instructions at: https://getcomposer.org/download/
To set up your first Laravel project you browse to the folder where composer has been installed (with something like cd E:\Programs\XAMPP\php in your terminal/command prompt and then you enter:

php composer create-project laravel/laravel E:\LaravelBasics\ –prefer-dist

This particular command is telling composer to create a template of a project using the Laravel framework and set it up in the Laravel Basics folder of E: drive.

This will create all necessary files for a Laravel application.

Creating a Basic Application using Laravel

Users will see the public folder.

We have moved the LaravelBasics folder but you can see the path to access the application:

http://localhost:8079/current/articles/Laravel%20Basics/LaravelBasics/public/

The first thing that you have to do when starting to develop a Laravel application from scratch is to set Laravel to show errors. If you do not set this up you will always get “Whoops, looks like something went wrong” when there is something wrong with your code.

To do this, open app/config/app.php and set ‘debug’ to true.

Now open app/routes.php

Routes basically tell the application which controller should take a particular URL request or process it themselves by interacting with the model and the view (the view is what is going to be displayed to the user)

Add this route to the routes.php

This basically says that if the URL is

http://localhost:8079/current/articles/Laravel%20Basics/LaravelBasics/public/guess/10,12,15

or

http://localhost:8079/current/articles/Laravel%20Basics/LaravelBasics/public/guess/16 the file called guess.php/guess.blade.php has to be shown to the user (you do not have to write the file extension in the View::make()’s argument. A text in {} (curly brackets) means that a random input may follow the request (guess/) in the URL and ? means that it is optional for the URL request to have the random input for which the ? applies. Thus, if we open the URL without providing a number like that:

http://localhost:8079/current/articles/Laravel%20Basics/LaravelBasics/public/guess the view will load with the default number that we have given (6).

If we write Route::get(‘guess/numbers/’)… then onlyhttp://localhost:8079/current/articles/Laravel%20Basics/LaravelBasics/public/guess/number/ would lead to displaying the ‘guess’ view.

withNumbers($number); is a magic method, it is the same as with(‘numbers’, $number) meaning that the View ‘guess’ would be able to use the $numbers variable from the route/URL whenever it wants to use it. It could be explained as with(‘variable name in the view’, ‘variable to pass to the view’).

Then in app/views we create a file called guess.blade.php to make use of the Blade Templating Engine.

In the Blade’s templating engine {{ }} (double curly brackets) work just like PHP’s echo or print statements and {{{ }}} (triple curly brackets works the same way but they also sanitize the input).

You can see a quick demo in the code above of how to use if/else statements and foreach loops using Blade.

Now if we type an URL like:

http://localhost:8079/current/articles/Laravel%20Basics/LaravelBasics/public/guess/1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18 only our first 5 could-be-lucky numbers will be compared against the real lucky number.

To download the code associated with this article, visit the original place where the article was published: http://www.phpgang.com/laravel-4-basics-part-1_843.html

by

Transforming HTML characters

If we have some code, for example a search engine in our website which responds to get parameters and has the following snippet:

if (isset($_GET[‘q’])) {
echo “500 results for the query ” . $_GET[‘q’];
}

A legitimate user might get a page resembling something like this:

However, any user is going to be able to add tags to the queries and at the very least change drastically the way your page is formatted. For example, he can target particular browsers and send links with malicious GET parameters which would load external JavaScript files.

Above is an example of how we can easily change both HTML and CSS on the page (a relatively harmless example).

htmlspecialchars

To combat this, we can use htmlspecialchars(), htmlentities() or strip_tags(); htmlspecialchars() takes a string and as optional parameters – ‘flags’, the ‘encoding’ to be used when converting the characters and a ‘double encoding’ option which is set to true by default and when turned off forces PHP not to encode existing HTML entities.

A sample usage would prevent such XSS vulnerabilities and show the tags instead of applying them:

if (isset($_GET[‘q’])) {
echo “500 results for the query ” . htmlspecialchars($_GET[‘q’]);
}

However, htmlspecialchars only changes the ampersand, double quotes, and less and greater than symbols by default.

Thus, we could still get undesired effects. For example, here is a sample way to apply tags when the single quotes are not escaped.

Suppose we have the following snippet:

if (isset($_GET[‘q’])) {
$query = htmlspecialchars($_GET[‘q’]);
echo “500 results for the query ” . “<a href='” . $query . “.html’> $query </a>”;

}

A legitimate request would look like this:

The line just adds a link to the page that points to an HTML file (it would be dynamically generated) named after the sought keyword and displays the keyword as the text child node of the anchor. You can see that the $query variable is passed to the anchor and to the text which contains the escaped with htmlspecialchars() input.

However, consider if the user tries to see whether the single quote is also escaped and types something like:

http://localhost:8079/Tests/index.php?q=Chocolate’ style=’font-size:5em’

Then the user has successfully closed our anchor tag and added an arbitrary attribute. He can then try to add inline JavaScript and keep on testing for ways to exploit the vulnerability.

Figure 1: After the single quote exploit

Figure 2: Legitimate request (the anchor before the exploit)

To fix this, we just pass the ENT_QUOTES flag.

if (isset($_GET[‘q’])) {
$query = htmlspecialchars($_GET[‘q’], ENT_QUOTES);
echo “500 results for the query ” . “<a href='” . $query . “.html’> $query </a>”;
}

After we escape the single quotes as well, this vulnerability vanishes.

To transform an escaped string containing markup to markup, again we use:

Strip Tags

If you want to be more radical, you can remove all HTML and PHP tags from a string or remove only a selection of them. The built-in function strip_tags() takes a string in which to remove the tags and optionally another string that pinpoints which tags are allowed.

if (isset($_GET[‘q’])) {
$query = strip_tags($_GET[‘q’]);
echo “500 results for the query ” . “<a href='” . $query . “.html’> $query </a>”;

}

The above code results in all tags being removed from the string.

Optionally, we can allow any tag we want, but we have to do some manual escaping as users can enter whatever attributes they want. Of course, contemporary browsers have XSS protection, but there are still clients with older systems that could be targeted with such malicious links.

if (isset($_GET[‘q’])) {
// We are allowing only some of the text formatting tags but any type of attribute may be added to them by the user
$query = strip_tags($_GET[‘q’], ‘<p><b><em><strong><i><small>’);
echo “500 results for the query ” . $query . “</a>”;

}

We get an error in the console telling us that the XSS Auditor did not execute the script on up to date Chrome, but this would not be necessarily the response all users will get.

Htmlentities

Another function you can use is htmlentities()

The difference between htmlspecialchars and htmlentities is that htmlentities translates all HTML characters entity equivalents to the particular entities. This basically mean that it applies also to entities such as &copy; (the copyright symbol), &euro; (the euro symbol) and all others.

For example, if we use htmlspecialchars() and enter the euro sign we will get the following result:

However, if we use htmlentities, the euro character will be properly translated to its relevant HTML entity:

It is it important to know the default flag of htmlentities() is ENT_COMPAT, which only converts double quotes (single quotes are not translated like they are in htmlspecialchars()).

Therefore, you also have to use ENT_QUOTES where appropriate:

if (isset($_GET[‘q’])) {
$query = htmlentities($_GET[‘q’], ENT_QUOTES);
echo “500 results for the query ” . “<a href='” . $query . “.html’> $query </a>”;

}

Validating input

For most purposes the built-in function filter_var can be used. It is available in servers with greater than 5.2.0 version of PHP. It takes a variable or static input and returns false on failure and the filtered data on success. We can use it for validation and sanitization of input.

It has to be mentioned that filter_var’s validation mechanisms do not only tell you if the input is valid but also sanitize it by removing the illegal characters.

Below is an example of how it works:

if (isset($_POST[‘submit’])) {
$email = filter_var($_POST[‘email’], FILTER_VALIDATE_EMAIL);

if ($email) {
echo “Your email $email is legit. Save it into the database.”;
}
else
echo “Your email $email is invalid. Redirect to form.”;
}
?>
<form method=”POST”>
<label for=”email”>Email</label>
<input type=”text” name=”email”>
<input type=”submit” name=”submit” value=”Send”>

</form>

This script will display that the email is legit if it is a valid email or display that the email is invalid if it is not.

There are also validation filters for Booleans (FILTER_VALIDATE_BOOLEAN) which returns true only when the input is one of the following string combinations:

• “1″
• “true”
• “on”
• “yes”

In every other string value it will return false.

Another validation filter is for floating point numbers (FILTER_VALIDATE_FLOAT) which does not return false when:

• The input is a numeric floating point value (Example: 22.2)
• The input is a string containing a floating point value (Example: “22.2″, ’22.2′)

Optionally, you can pass an option – FILTER_FLAG_ALLOW_THOUSAND would allow a thousand separator such as a comma (,). FILTER_FLAG_ALLOW_SCIENTIFIC would allow the number to be in scientific notation (e,E) and there is also FILTER_FLAG_ALLOW_FRACTION.

The FILTER_VALIDATE_INT filter would return the filtered integer or false on failure to extract an integer. There are flags to allow octal and hexadecimal numbers (FILTER_FLAG_ALLOW_OCTAL and FILTER_FLAG_ALLOW_HEX) and the ability to extract a number from a specified range. Here is a sample:

Options are passed in a two-dimensional array. The parent array contains the ‘flags’ index and ‘options’ is a nested array with all options where the key is the option name and the value is the value that the option should have. Here is how we can validate an integer to be between 1 and 100 and allow hexadecimal values.

When we pass 120 – false (or 0) is returned and we get a message that the number is invalid:

Your int 0 is invalid. Redirect to form.

If we enter 85, 85 is stored in $int and we get this statement:

Your int 85 is legit. Save it into the database.

Similarly, if we use a hexadecimal value below 100 (let’s say 10), the integer also passes the validation:

We are going to show one last example with the URL filter:

if (isset($_POST[‘submit’])) {

$options = array(

‘flags’ => FILTER_FLAG_QUERY_REQUIRED

);
$url = filter_var(“http://www.dimoff.biz”, FILTER_VALIDATE_URL, $options);

if ($url) {
echo “Your URL $url is legit. Save it into the database.”;
}
else
echo “Your URL $url is invalid. Redirect to form.”;

}

We are validating an URL and passing a flag to allow only URLs with a query string attached to them (a GET parameter). We get the following response:

Your URL is invalid. Redirect to form.

If we instead try the following URL, we will get a positive response:

Your URL http://www.dimoff.biz/?id=1 is legit. Save it into the database.

The drawback of the validation is that internationalized domain names would always fail validation (only Latin URLs will pass the test – those containing ASCII characters).

There are also filters to validate regular expressions and IP addresses (both IPv4 and IPv6).

You can check filter_var_array(), which can filter multiple variables inserted in an array at once.

3.1 Validation through regular expressions

There are times when the built-in validations are not sufficient or do not include the validation you require. In such cases you can use preg_replace, preg_match, preg_match_all or preg_grep to do the job.

For example, you may want to allow both Bulgarian and American zip codes. However, Bulgarian zip codes consist of 4 digits, whereas American zip codes consist of 5 digits.

To do this you can use regular expressions:

<?php
if (isset($_POST[‘submit’])) {
$zip = $_POST[‘zip’];
$is_zip = preg_match(“#^[0-9]{4,5}$#”, $zip);

if ($is_zip) {
echo “Your zip code $zip is legit. Save it into the database.”;
}
else
echo “Your zip code $zip is invalid. Redirect to form.”;

}
?>

<form method=”POST”>
<label for=”zip”>Zip Code</label>
<input type=”text” name=”zip”>
<input type=”submit” name=”submit” value=”Send”>

</form>

This regular expression tests if the input starts with a number which is repeated 4 or 5 and times and then ends. Here are some tests:

Your zip code 23135 is legit. Save it into the database.

Your zip code 2313 is legit. Save it into the database.

Your zip code 231 is invalid. Redirect to form.

Your zip code 231352 is invalid. Redirect to form.

3.2 Regular Expressions 101

Regular expressions in PHP must start and end with the same delimiter (usually /expression/ is used).

^ checks whether the input starts with something.

$ checks whether the input ends with something.

A value in square brackets [ ] means one of a particular character, for example [Abc] means the input can either be A or b or c.

[A-Z] means the input can be a single character anything between A to Z, for example M or D.

Uppercase and lowercase characters differ, so you would have to use [A-Za-z] if you wanted any alphabetic character. Similarly you could use 0-9 or d (which is almost the same but it includes some other characters).

? means the character preceding it can be repeated 0 or one time.

+ means it can be repeated one or more times.

* means the item can be repeated 0 or more times.

Alternatively you can provide a minimum number of repetitions [A-Z]{10} ( at least 10 characters) or a minimum and maximum number of characters [0-9]{4,5}.

. stands for any character (.? would mean any character zero or one times).

To escape these characters that are used within regular expressions and test for their literal character, you use backslash ( ). For example, #[A-Z+]#.

There are also some escaped characters with special meanings such as d for digit and s for space.

Characters enclosed in brackets signify that the values should be captured for future use. For example, you may try the following regular expression: preg_replace(“/([0-9]{4,5})-([A-Z]+)/”, “($1)$2″, $input);

If you give it a string such as “5432-PA”, it will transform it to become (5432)PA.

Preg_replace takes a regular expression as a first argument, the replacement string as second, and the variable to look into as third.

In the replacement string, $0 would give the whole original string, $1 would be the first bracketed item, $2 the second and so on.

Also, a way to filter input is using the ^ symbol in the beginning of square brackets in a preg_replace call. It would mean replace everything different than the values following the caret (^).

For example, preg_replace(“/[^w]/”, “”, $input); would cause input such as <script>alert()</script> to be filtered to “scriptalertscript”

w essentially matches all word characters and we are saying to replace all non-word characters with nothing.

Conclusion

We have covered some essential practices when working with input and we hope that you can start creating applications that are a little bit more secure and robust, or refactor existing projects by making them more secure with filter_var, regular expressions, or by filtering possible HTML coming from inputs.

To download all the code associated with this article and read the original publication, open: http://resources.infosecinstitute.com/website-hacking-part-vi-input-validation-filtering-php/

by

This is a practical tutorial of using SimpleXML to read XML files.

We start with the standard html skeleton, include our WordPressFeed class and start feeding it with feeds.

You can see that we have included the styles for the table in the head but you can include them in an external stylesheet and change them easily.
Then we define our class (comments are directly inserted in the code for the class):

Feed’s data can be retrieved the following way:

Then the raw results (an array of all posts/articles and their data) can be accessed with the public property:

The utility function to display the data in a table can be used the following way:\

It is important to cast the XML elements as string otherwise they would be SimpleXML objects. Also, in XML elements entitled something like dc:creator mean that the creator element is in the dc namespace and that namespace has to be accessed and the creator element retrieved.

You cannot simply access it with something like:

When we give it a WordPress feed and call the showTabular() method on the class we get a page that resembles something like the graphic below:

To get the code for this article, please visit: http://www.phpgang.com/using-php-and-simplexml-to-parse-wordpress-feeds_824.html

by

1. Storing your email address and telephone number in <a href=mailto:*> and <a href=”tel:*> and the inherent drawbacks of these methods
2. Shortcomings of disguising email in markup to avoid spam and other malicious requests (disguise such as mail [at] mail [dot] com)
3. Pitfalls of CDNs (Content Delivery Networks)
4. A widely used code snippet that is subject to XSS attacks
5. Relying on the HTML markup for important data for the application (such as product prices)
6. A loose security mechanism in an Australian governmental website.

Avoid giving sensitive information in a plainly visible way in the HTML markup

We all know of the <a href=mailto:sample@sample.com>Mail Me!</a>. However, giving out your email like this makes it pretty easy for bots to filter out your email and place it in a database/file, whatever they desire, making you subject to spam and other malicious attacks.
To illustrate, I have created a sample script that gets all results for “mailto:” and <a href=”tel: xxx-xxx-xxxx”> from https://meanpath.com/ and stores it in a file or displays it to the browser. This script is just a sample and assumes that all results are on a single page. Furthermore, MeanPath shows only 100 rows from the results unless you pay to get all of them.

Regular expressions are used to filter only those results that contain valid email addresses shown directly in the anchor tag. And for the telephone mining, it just gets the phones that are in the xxx-xxx-xxxx format. The code also ensures that no duplicate emails/telephones are entered into the list of the data.

Figure 1: A view of some of the collected emails and telephone numbers.

A better way to mine such data would be through http://www.nerdydata.com.

Figure 2: First part of the code. It creates a MeanPath class with a function called mine_elements() which gets all results from MeanPath and stores it in an array. The other function filter_elements() filters only the elements that match the query that was given in the instantiation of the MeanPath object and also makes sure there are no duplicate entries.

Figure 3: Second part of the code. The function display_data() shows the data in a ordered list in the browser. The function save_data_to_file() saves it on a random file, given when calling the function. Lastly, the MeanPath class is instantiated and data saved to a file and displayed in the browser.

Thus, it should be evident by now that giving personal information should involve some safeguards. Of course, this is not always necessary.

I also have to say that “encoding” the email in a format such as “sample [at] sample [dot] com” or “sample [at] sample . com” does not make it any more secure.

Here we have a short snippet of code. There is an HTML paragraph with an email given in it in that format and a PHP code that gets the file and extracts the email with a silly regular expression that extracts it and saves it into an array. The regular expression checks for any number of characters followed by [at] or @, followed by any number of characters after which there are some of the top-level domains.

Here is the browser result of the search:

matches[0] is the full expression that matched our search, matches[1] is the first parenthesized part of it that matched, and matches[2] is the second parenthesized part of the regex, and so on.

Use CDNs but be aware of security implications

CDNs (Content Delivery Networks) are a great way to decrease page load time (both because they often provide the script in numerous countries and load the one that’s closer to the user) and because users may have already cached the script by visiting another site which uses that particular CDN. However, there are security risks in that you have no control over what is stored in the loaded file. If the CDN gets compromised, the code in the file you are loading may change, and that can lead to more than just cookies being stolen. Also, the script loaded from the CDN can become unavailable, temporarily or not, leading to a frustrating user experience. If the file was on your domain and your site went down, the users would know there is a problem with the site, however if a CDN file such as jQuery gets unavailable and you are relying on it heavily – they would not know what is happening – the site would be up but it would look completely out of whack.

First off, the attacker can change the source code of the delivered script, and:

1. Replace your design with whatever he wants. Also, the attacker can execute JavaScript snippets if the user is using IE or Firefox (considering it is a .css file).
2. Replace the code to frustrate users, redirect your site to another one, steal users’ cookies and load any kind of exploit code he wants.
3. Gain server-side control if the delivered file is a JavaScript file.

Figure 4: Executing arbitrary JavaScript within CSS

Expression() works for some modes of IE8 and the ones below IE8 (particularly IE7 and IE5) which are still used nowadays. We see a very simple HTML 4.01 page which sets a cookie on each visit to the page without checking if it exists when the page loads. After that we have a <style> tag in which we pick a selector and a property and add expression(code here) to it where arbitrary JavaScript code can go inside. For example, you are loading a .css file via CDN (let’s say a CSS reset) this could be a potential security risk.

Figure 5: Here is how the page looks in Internet Explorer 7.0 on Windows XP (Emulated from browserstack).

As we can see, the expression ‘do’ gets evaluated and the cookie shown. We can do much more than this, but we will leave that to your imagination.

Figure 6: The same page in a contemporary browser (latest version of Chrome)

Another thing that can be done with control over the CSS is the following:

Figure 8: Using a CSS CDN – possibilities

Now, not only does a probable CDN have the ability to remove all of your content from being displayed to users, but it can add custom text to it, possibly acting as a fake redirect message and scaring/confusing your users enough to make them never come back to your site.

Only two CSS selectors are necessary to make such a change to your page, and the code does not assume any level of knowledge of the HTML markup in the page:

As for using CDNs for JavaScript files, I hope you do not think that it is only possible to steal the JavaScript cookies and mess around with the DOM when the external file is compromised. It takes 2-3 lines of code to load any server-side file via AJAX.

To simulate a JavaScript file loaded from a CDN, we added a local .js file to the recipes page I’ve shown earlier.

Then in the file we executed the following:

And in the PHP script we had this:

This worked as the picture below shows:

Now the attacker has much more power over both the server and the website.

You can see one of the previous articles of the series that concerned PHP Injection and learn some of the things that can be achieved from now on.

XSS is everywhere

Another thing to be on the lookout for is XSS. It comes in many forms, but here we will give one example that is sometimes unknown for developers. In PHP $_SERVER[‘PHP_SELF’] is vulnerable to cross-site scripting. Often, it is used as part of a <form> action attribute. It should always be escaped with something like <form method=”GET” action=”<?php echo htmlspecialchars($_SERVER[“PHP_SELF”]); ?>”>.

Figure 9: An example of a page vulnerable to XSS. Do not pay attention to the poor nesting.

What the <form> action does is just echo the URL that the user is currently in. This means that he can easily manipulate the URL to include code and the browser will execute it. He can also give links with manipulated URLs of the site to third-users and get something from them. All he has to do is close the action attribute and close the <form> tag. Thus, he has to type “> and insert HTML code after that in the address bar.

Figure 10: XSS example

Above we see a JavaScript snippet executed in the address bar which alerts “Hi” (localhost:8079/4/php_self.php/”> <script> alert(“Hi”);</script>). Google Chrome would break requests like this, but Firefox does not do it that well.

Setting important data for an application in the markup

To illustrate, I have taken some screenshots from a search in nerdydata.com for the keyword data-price=”

Figure 11: data-price=”$269.99″. It could be generated dynamically just to show the price with JavaScript.

Figure 12: data-price”75″ and a data-tid=”51127″ (the ID of the product is also set in the HTML markup)

Figure 13: close to 14,000 websites with price set in the HTML markup. At least a couple of them will be vulnerable to user manipulation of the price.

I do not think that I am wrong by saying that at least a couple of sites from those 14,000 will not have proper mechanism set up on the server side to check for the product’s price by checking the product ID or name and getting the prices from a database.

I also want to show this way of storing the price:

Figure 14: <input type=”hidden” name=”price” value=”59″>, <input type=”hidden” name=”item_id” value=”…”>

Figure 15: 7087 websites with hidden input containing the price of the product.

Mo’ Captcha, Please

Figure 16: Site of Australian government…

In the picture we see a page from the site of the Australian Customs and Border Protection Service which does not have any of the fancy CAPTCHAs (I agree that they may prevent also legitimate users from using the site, but it is more positive than negative).

The security mechanism in the abovementioned site seems static; the bold numbers do not change. In case they changed:

I have created a snippet which fetches the numbers, considering they weren’t static, and this was their security verification method – showing and making you type different numbers in bold text next to other characters, all of which are fully visible in the HTML markup.

Figure 17: This snippet fetches the page from their site and displays it in an unseen div so I can traverse the data with jQuery. The jQuery code then loops for each <strong> tag and adds its text to a variable, separating different strong tags by whitespace on both sides. Then a regex is called, which matches only numbers followed by whitespace on both sides and converts the resulting array to a string. Finally, all whitespace is removed from the mined numbers and their values are shown in the console and in an alert.

Conclusion

I hope those tips have helped you, whether a lot or a little, to see common mistakes and possibilities for mistakes in web applications. If you want to have all the source code, you can download all the files with PHP, HTML, CSS, JavaScript and JQuery code used in the article from InfoSec Institute: http://resources.infosecinstitute.com/website-hacking-part-iv-tips-better-website-security/

by

In this part of the Website Hacking series we are going to take a look at how to minimize damages from XSS attacks considering our web application can at some point become vulnerable to this type of attacks (HttpOnly cookies are going to be discussed). We are going to look at a mechanism for bypassing the security that HttpOnly cookies provide known as Cross Site Tracing attack. We are also going to give a brief example of packet sniffing, followed by a more lengthy discussion on session hijacking and session fixation.

Minimizing damages from XSS (HTTPOnly Cookies)

If your site at some point becomes vulnerable to XSS, you probably know that your cookies would be exposed. The attacker can simply save document.cookie’s value somewhere and use it for malicious purposes – for example – he can try to steal your session by looking for a session identifier in your cookies. As you know, the main difference between cookies and sessions is that cookies are stored locally on the user’s machine, and sessions are stored in the server (usually the tmp folder, which has to be ensured is out of the public folder and out of reach for regular users). However, the way sessions work is that they save an ID which links the user with the particular session stored on the server, and this session ID (known as magic cookies or session keys) can be stored and passed to the server in a cookie.

Here is one way to make sure that if somebody could get the document.cookie from your users, he does not get all the cookies you have stored for that user.

Read the following setcookie description below (as taken from php.net)

A way to ensure that if an unauthorized person can execute JavaScript on clients he would not get the cookie is to set the last parameter ($httponly) to true. This will disallow JavaScript from reading the cookie that you are setting.

A sample cookie would look something like that:

$username = "Cartman";
$cookie /* true/false */ = setcookie("user2", $username, 
	0 /*expire at the end of the session */,  
	"/"  /* available within the whole domain */,
	 "", false, true /*HTTPonly; no JS access */);

Then you can easily access it with PHP with something like that:

Even better, there is a way to make sure all your cookies are HTTPOnly:

You can set in your php.ini file session.cookie_httponly to 1 or force HTTPOnly cookies only for particular pages/scripts on your website by adding:

// Make session cookies httponly
ini_set('session.cookie_httponly',1); 

in the page’s header.

Another way to add an HTTPOnly cookie (a more low-level one) is to set the header yourself:

// A more low-level way of setting a httponly cookie
header("Set-Cookie: user2=Kenny; httpOnly");

HTTPOnly Cookies circumvention and prevention (XST)

We have seen that HTTPOnly cookies disallow access to the cookies from JavaScript. However, a technique was crafted to circumvent this protection. It is known as XST or Cross Site Tracing Attack.

The attacker could target old browsers and type something similar to:

Similar AJAX XST attempts should not work on clients having Firefox 19.0.2+ or Chrome 25.0.1364.172+

Thus, it may still be useful to block Trace requests.

To disable it natively, Apache’s httpd.conf must be opened and the following line added to it:

TraceEnable off

This would work on versions of Apache > 1.3.34 or 2.0.55+ for apache2.

Another way to disable TRACE methods without changing the htpd.conf file is changing the .htaccess file and adding:

Note: mod_rewrite has to be enabled for the snippet to work.

Packet sniffing

There are many sites out there whose client credentials are vulnerable when it comes to man-in-the-middle attacks. When connected to a public Wi-Fi, there could easily be someone at that restaurant sniffing the incoming traffic. Here is a sample using Wireshark:

Firstly, we have applied an HTTP filter to only see HTTP requests.

Then we use Ctrl+F, search for a String and enter “POST” for value to only see the POST requests (in most cases, those contain user-entered data and frequently interesting ones).

Here we see a sample of unencrypted client/server communication after a registration form has been submitted.

A fix for that is using HTTPS (TLS/SSL).

Session hijacking/Session fixation

Assuming another vulnerability is present (such as XSS), an attacker can see users’ cookies, then he can see which one is the session ID (by default in Apache servers the session id is carried in a cookie called PHPSESSID and hijack an active session. Below we have provided an explanation of how that could happen. Assume we have this login script and login form on the same file (in a real application the accounts would be populated from a database).

We can see that in the upper left corner there is a paragraph with the text “User appears NOT logged in” before the user has been logged in.

Note: we have enhanced the form visually a bit with Bootstrap 3.

The code is as follows:

session_start();
if (isset($_SESSION['account'])) {
	echo "<p>User appears logged in.</p>";
}
else {
	echo "<p>User appears NOT logged in.</p>";
}



?>

<!DOCTYPE html>



<html lang="en">
<head>
	<link rel="stylesheet" href="css/bootstrap.min.css">
	<meta charset="UTF-8">
	<title>Login</title>
</head>
<body>
	<div class="container">
		<div class="row">
			<div class="col-lg-6 col-lg-offset-3">	
				<form class="form form-vertical" action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']); ?>" method="POST">
				<div class="input-group">
					<span class="input-group-addon glyphicon glyphicon-user"></span>
					<label for="username">Username:</label>
					<input name="username" id="username" class="form-control input-lg" type="text">
				</div>
				<div class="input-group">
				<span class="input-group-addon glyphicon glyphicon-lock"></span>
				<label for="password"> Password </label>
				<input type="password" class="form-control input-lg" name="password" id="password">			
				</div>
				<div class="submit-container text-center">	
						<input type="submit" style="margin-top: 15px;" class="btn btn-lg btn-success" value="Log in">
				</div>
				
				</form>

			</div>
		</div>

<?php


$accounts = array("Cartman" => "overweight", 
	"Kenny" => "diesoften",
	 "Kyle" => "jew", 
	 "Chef" => "ladiesguy");


if ($_SERVER["REQUEST_METHOD"] === "POST") {
	$username = $_POST['username'];
	$pass = $_POST['password'];
	foreach ($accounts as $account => $accountPass) {
		if ($account == $username) {
			if ($accountPass == $pass) {
				echo "<h1 class='text-center'>Logged in as $account!. Redirecting... </h1>";
				$_SESSION["account"] = $account;
				sleep(1);
				header("Location: memberzone.php");
			}
				
			}

		}

		 if (!isset($_SESSION["account"])) {
		 	echo "<h1 class='text-center'>Wrong credentials.</h1>";
				
	}
		 }
?>


		</div>
	</body>
</html>

We do not implement an actual attack but check our session ID cookie:

Then we open the page in a browser that does not have any active sessions, start Tamper Data and submit the form with wrong credentials, but use the session ID of the actual logged in user.

The result is: we have hijacked the session of a legitimate user and appear logged in. (We do not get redirected, but as you can see we are logged in and there’s no wrong credentials statement appearing).

Actually, as you can see we are not redirected to the memberzone, so the code inside the if ($accountPass
==
$pass) conditional does not execute, but if we have code executed in another block, which depends on the user being logged in or similar, then the attacker would have been able to run the code inside it and do whatever he wants with the user’s account.

The first and more ineffective way of protecting against such attacks is to set session.referer_check = yourDomainHere in php.ini or use ini_set to set it for a particular script. In that way, the session would be set only if the set domain/path is the referrer (equivalent to $_SERVER[‘HTTP_REFERER’] regular expression search in a sense and not a very effective method). Plus, it does not accept multiple parameters. Multiple parameters are supported in some frameworks such as CakePHP.

What you should do is protect yourself against XSS attacks, as these can leak the session ID and lead to session hijacking. You should also use httpOnly cookies to revoke JavaScript access to your cookies, possibly minimizing damages from XSS and not leaking users’ cookies.

Another thing you can do is to check if the IP address of the person who first logged in and the IP address of the person using the session are the same (they are expected to be the same).

Firstly, we make the following changes (check if there was a session hijacking attempt, say to the user that he has been reported and send an email):

In our loop that checks whether some of the credentials match, we have to also log the IP address of the person at the moment of logging him in.

$username = $_POST['username'];
	$pass = $_POST['password'];
	foreach ($accounts as $account => $accountPass) {
		if ($account == $username) {
			if ($accountPass == $pass) {
				echo "<h1 class='text-center'>Logged in as $account!</h1>";
				$_SESSION["account"] = $account;
				$_SESSION['IP'] = $_SERVER["REMOTE_ADDR"];
	
			    }
				
			}

		}

And we modify the section when we show content only for logged in users to something like:

session_start();
if (isset($_SESSION['account']) && $_SESSION['IP'] === $_SERVER["REMOTE_ADDR"]) {
	
	// Code to be executed for logged in users can be placed here
	echo "<p>User appears logged in.</p>";
}
else {
	echo "<p>User appears NOT logged in.</p>";
}

We have logged in with Chrome as Kenny.

We use a different IP address and try to steal the session with the session ID cookie credentials using Tamper Data.

We get the following page:

User appears NOT logged in (we have not fooled the script) and a notification that the breach was found is displayed on the screen. And if we look at our email client, we will get a message resembling this but with the full IP address of the attacker written in the email’s contents:

Session fixation is different from session hijacking because in session hijacking the attacker could intercept or hijack the session’s cookie, but in session fixation the attacker supplies the user with a session ID that is already set, and when that user logs in the server would assign his data into the session ID that is set by the attacker, which would grant him access to the user’s session.

To prevent session fixation, one way is to check the referrer (we have mentioned that before). Another way is to reduce the duration for which sessions are active from another php.ini setting (session.cache_expire).

However, what we recommend is that you regenerate session IDs frequently.

Assigning a new session ID will ensure that the ID that a possible attacker has obtained would not be useful, because a new session ID would have been assigned to the user.

We can achieve that with the following snippet:

session_start();
if (!isset($_SESSION['check'])) {
 	session_destroy();
 	session_regenerate_id();
	$_SESSION['check'] = 1;
} 

Conclusion

In this article, we have examined some common exploits out there, and we hope that you will start implementing some of these security mechanisms in your future projects, if you are not implementing them already.

Sources:

1. MDLog:/sysadmin, “Apache Tips: Disable the HTTP TRACE Method”, Accessed 3/12/2014, Available at:http://www.ducea.com/2007/10/22/apache-tips-disable-the-http-trace-method/
2. OWASP, “Cross Site Tracing”, Accessed 4/12/2014, Available at:https://www.owasp.org/index.php/Cross_Site_Tracing
3. Stack Overflow, ‘What is PHP’s session.referer_check protecting me from?’, Accessed 5/12/2014, Available at:http://stackoverflow.com/questions/4863946/what-is-phps-session-referer-check-protecting-me-from/

This article was originally published on InfoSec Institute

by

In this Part, we are going to briefly introduce Path Traversal, usage of Delimiters, and Information Disclosure attack.

We are going to present simple solutions to simplified problems involving the attacks.

Content

Exercise 8: Path Traversal

Figure : A simple webpage in which you choose an article and view it

The website (index.php) in the PathTraversal folder contains a simple form which submits to the same page through the GET request method. Once a choice of article has been made and “View article” has been clicked, the following PHP code executes:

The result is the following URL: http://localhost/2/PathTraversal/?article=1.htm

It loads the relevant article file placed in the GET method. The parameter article is formed via:

And the values are also directly given through the HTML code (the value attribute):

Domain Slamming

Now, legitimate users will use the interface provided in the website to browse it, but with the code as it is we can easily open myriad files they do not want you to open by directly tampering with the URL parameters. Many websites have config directories where they store important data – let’s see if you can do it.

Tasks

1. Go back one directory and open openme.txt by changing the URL parameters.
2. We assume that we cannot open the folder config from our computer but only from the local server. Assume you do not know what files there are in the directory. First, you should check whether the directory exists.

   

The directory exists and now we know that there is HTTPAuth in place. Your task is to somehow find out the username and the hashed password for the folder without using any brute-force or dictionary attacks on the username and password.

Spoiler (Task 2)

If we know that there is a HTTPAuth security mechanism in place, then we can automatically deduce there is an .htaccess file. Therefore, we can open the .htaccess file that we would not be able to open normally via the path traversal vulnerability of the article viewer page.

Figure: Viewing the .htaccess file from the article viewer page

We type http://localhost/2/PathTraversal/?article=config/.htaccess and now we know the path and the file in which accounts and passwords are stored as well as the user that is required to view the folder.

We type the path to the userlist.htpasswd file and get all usernames and passwords:

tomburrows:$apr1$ZF.78h2N$zhAaP2AY6VwxuELizJAwg.

Now, the username is known and we have incredibly reduced our cracking time. HTTPAuth is using UNIX’s “CRYPT” function to encrypt the passwords which is a “one way” encryption method.

Using path traversal, we can also go back several directories and browse to the php.ini and other important configuration files as well.

A sample solution to our path traversal vulnerability

The change in the HTML code is that we no longer use the full file name value in the options tags, we just use the name of the file (without its extension so only .htm files would be allowed)

Firstly, checking if the file exists and echoing it out only if it exists prevents another attack – that of information disclosure.

There is a PHP warning thrown out if we type a non-existent file deliberately. Of course, another way to resolve such information disclosure issues is by turning off the display_errors In the php.ini file (this is most desirable if the site is live anyway).

With the above mentioned code we get a clean and neat error that the article does not exist, along with prevention of any path traversal attempts.

Figure: We now receive an error when we try to go back one directory and open the openme.txt file

Note: in old editions of PHP (older than 5.5.3) you could use the %00 marker to end the string abruptly and pass your own file extension in place of the “.htm” one in our solution code.

if (!file_exists($article . “.htm”)) could be exploited in older versions of PHP by typing:

http://localhost/2/PathTraversal/?article=accounts.txt %00

Which is equivalent to:

“accounts.txt.htm” forcing the server to ignore the .htm part of the string.

Exercise 9: Information disclosure

Figure: Comment page

For this exercise, I have created a working but problematic comments page which looks similar to a chat. You have to write a comment, and then you view all the comments up to now. The comments are stored in a .txt file rather than in a database and there is one PHP file that creates new comments and one that displays them on the screen.

Figure: How the comments file looks

This application works just fine when viewed as is, but imagine if a user enters add_comment.php separately, without the file being included from the index.php. This can easily happen as the name of the service implies the file name, and this particular file name is frequently used, and the fact that add_comment.php is in the same directory facilitates the process.

Figure: Viewing add_comment.php on its own

Now, the attacker would know that we have a variable called $path and he can probably guess that we are setting the path to the comments file as there is a warning that file_get_contents(comments.txt) cannot be opened. Thus, he knows the name of the file that contains all our comments as well. Because the include is failing, he also knows the whole include_path which can also be dangerous. Also, the attacker knows another file in our directory tree (view_comments.php) so he can access it and look for some more errors. He also knows that in this file we are working with the POST values from the form, as he can view the HTML and see they are the same.

This comments form is also vulnerable to diferent code injection attacks. You can easily insert in one of the comment fields to test it out. In that way, the browsers of the users’ will execute any code that you like each time they visit the page.

A probable solution is easy: wrapping the post values in htmlspecialchars() function which converts < and > amongst others as special characters (<, >, etc.) preventing them from being interpreted as code.

$newcomment[] = htmlspecialchars($_POST[“name”]);

$newcomment[] = htmlspecialchars($_POST[“topic”]);

$newcomment[] = htmlspecialchars($_POST[“message”]);

Solution

A simple solution to get rid of all those errors in this example is to wrap the code in add_comment.php and view_comments.php inside the following if statement:

To read the entire article, please go to: the article in InfoSec Institute

by

Websites are used daily by a large part of the world’s population to carry sensitive data from a person to an entity with online-based presence. In websites containing materials that are shown after authentication only, forms transfer data containing user credentials to server-side scripts. Users store their credit card details in their online accounts and use forms to buy items online, so it is crucial to keep the integrity, confidentiality and availability of this data intact.

This article is written merely with penetration testing and website security in mind. Any attempts to penetrate into live systems on your behalf and without consent may lead to criminal proceedings.

To try the training files that come along with this article, you would need a local server such as XAMPP or WAMPP with Apache and preferably MySQL turned on. If you are on Windows, to install Hydra you would need to install make, gcc and ssl libraries of Cygwin. Therafter, you would need to start it with the Cygwin Terminal. John the Ripper, on the other hand, can be started from the Command Prompt.

Exercise 1: Deep Data Hiding

In the past, and even today, some people have used security through obscurity. This means that they have unprotected directories and files with the sole protection being that they do not have any backlinks and no links to them in the main site. Thus, if one knew the URL of the directory or file – he could readily access it. A common way to reveal obscure directories is to check the publicly visible robots.txt and see what is disallowed to be indexed by search engines.

Now open the DeepDataHiding folder through your localhost and try to find the hidden directory where uploaded .doc files from “users” are stored, then access it. If you upload a .doc file to test this out, in the main page of the directory – it won’t leave your computer.

Exercise 2: Populating a Dictionary

To populate a dictionary, we will be using John the Ripper. Open the PopulatingDictionary folder.

You can populate a dictionary in John the Ripper and cut the output size by knowing the type of password (its maximum length, whether it should be only digits, contain special characters, etc.).

To create a simple dictionary and save it to a file, you can browse to the directory of the john the ripper installation in CMD and use: john-mmx –incremental=alpha –stdout > filename whereas filename is the name and location of the file in which the words should be saved to.

There are various options in the incremental mode, such as Digit (only digits), Lanman (letters, numbers and some special characters), Alpha (only letters) and All (all characters). Thus, you can also use john-mmx –incremental=lanman –stdout > wordlist.txt, etc.

Be aware that the size of the text file would probably get really big in just a couple of seconds, depending on your machine’s abilities.

Exercise 3: Acquiring user and password list for dictionary attacks

Querying Google for passwords and user lists is usually pretty straightforward.

You use something like filetype:lst password for passwords and filetype:lst user for username lists.

We have included a sample username list and a password list downloaded from the Internet along with the attachment files to this article.

Exercise 4: Breaking HTTPAuth

For this exercise, we will be using Hydra and the user/pass lists included in the attachment files.

When calling Hydra ($ hydra.exe) the parameter –L usrlistpath serves the purpose of supplying the program a path to a username list file whose usernames will be tested along with all the passwords until a match is found. –l username gives Hydra a single username, which option can be used if you know the username you are trying to break into but do not know the particular password.

-P loads a password list while –p loads a single password.

Next, you specify the host to attack (localhost or 127.0.0.1) followed by http-get (request a directory/page), followed by the path to the particular directory or file you are trying to access (path excluding the host which is already given). It will most likely look something like this:

hydra.exe -L HD:/WebsiteHacking/FormCracking/usrnames.txt -P HD:/WebsiteHacking/FormCracking/passwords.txt localhost http-get /HTTPSecurity/

Figure 1: the HTTPAuth seeking credentials. Get them!

To establish a simple HTTPAuth mechanism yourself, you need to create your password by browsing to htpasswd.exe in your Apache bin folder, starting it in Command Prompt, and creating it. You can move the user account list file to any directory you want and start the mechanism by editing your .htaccess file:

You can select only particular users to be able to access the page, and you can set different username lists for different parts of the website, but this mechanism for protection remains basic. To test cracking the example from the files, change the path of AuthUserFile to the current location of the HTTPSecurity directory.

Exercise 5: Breaking a POST login form

The password and usernames list are in the FormCracking folder. They have not been changed, but the correct login credentials are easy enough.

The following statement might work:

hydra –L path/FormCracking/usrnames.txt -P path/FormCracking/passwords.txt 127.0.0.1 http-post-form

“/FormCracking/index.php:username=^USER^&passwd=^PASS^:Oops”

The difference between this statement and when we cracked the HTTPAuth mechanism is that here we include the parameters that the form sends to the server-side script, in this case username and password. Those are the “name” attributes of the relevant input tags that we want to test.

Figure 2: viewing the POST fields.

Another difference is that after the address that we want to crack we include separated by a colon ( : ) the text that shows when the login submission is incorrect. Basically, we are telling the program to repeat until it gets a different output. In our case, we have “Oops” as a part of the login error string we receive.

We also include ^USER^ and ^PASS^ after each POST field that must be filled with the data from the username and password lists by the program.

Then, we wait and the job is done.

Exercise 6: Modifying Parameters

The next exercise is in the folder ParameterTampering. Open ParameterTampering/login.php with your browser. Your task is to bypass authorization or login with wrong credentials without viewing the server-side code and accessing members.php message and members2.php without the “Error!”. You do not have to crack the user details. For one of the methods, you must see what logging in looks like – use john/123

The first manner in which you can do this is by modifying an element in the page, the second involves a change in the URL.

The other task is to enter in members2.php without the server echoing “Error”. To do this, you should tamper with the HTTP Headers and add a referrer. I would recommend a plugin such as Tamper Data for Firefox or Request Maker for Chrome.

Answers:

1st possibility:

Figure 3: modifying the values of hidden inputs.

It might seem weird at first, but many sites actually have hidden inputs in which they store important data. An example is PayPal shopping carts on third-party websites where you can change fields such as name of the product directly by changing the value of a hidden input. There are some outdated shopping carts which still use price as a hidden input which means that if you don’t use their API and verify the amount that was paid to you through a server-side script – the user can easily pay as much as he wants for the product!

Figure 4: an example of a shopping cart which sets the price of the item on the client-side.

Figure 5: changing the name of the product in stores using PayPal as a payment method can still do some harm.

2nd possibility:

Setting a loggedin GET request, that’s probably not something you would meet somewhere today though.

3rd possibility, members2.php:

Install and start Tamper Data with alt+T when the page is opened. Add a new Header…

Called Referer and with value the path to login.php, it would look like you were redirected from login.php. There are developers out there who think HTTP_REFERER proves that the user is legitimate despite that it’s just a header sent through HTTP requests, and this is a point of exploitation in some sites even today.

Exercise 7: Exploiting Account Lockout

To read the entire article and download the practice files, please go to: the article in InfoSec Institute

by