[Security Discussion] Kjcooling:
Hi all,

As part of a class I'm doing, we are required to post some content to a forum to engage in discussion on security:

.

Cross Site Scripting (XSS)

OWAPS describes Cross Site Scripting (XSS) where a website has been marked as a trusted website, which for some reason, can run malicious code or scripts through inputs such as forms. As the end user’s browser sees this site as trusted, it allows the malicious script or code to execute, which can give access to client side information before it is encrypted (such as usernames, passwords, session IDs, cookies, etc).

In PHP for example, a normal input box where a user would enter their name, would be able to enter the following:

When PHP prints this back out after submission, it will execute the script between the script tags (In this case, just a simple popup).

In this scenario, this can be solved by wrapping the input value with htmlentities:

This would print any script as literal text rather then executing it.

In Java,

XSS is still a major issue, both due to some sites not implementing simple work around such as htmlentities or htmlspecialchars, or for reasons where these cant be used. XSS affects PHP applications by as much as 86% - its PHPs biggest vulnerability.

In Java, the easiest method is to simply validate inputs and to encode special characters (<>?!@#$%^&*). Alternativley, OWASP have a XSS class which includes easy methods to best prevent against certain types of XSS.

Code Injection

Code injection is where using the sites scripting language, you can inject (rather, have the site pull) code from somewhere else.

For example, php can call one of its own pages like so:

however, if we replace the contact.php page with an external hosted script:

This will cause the enduser to execute that script. This all comes down to PHP validation which is coded within the PHP to ensure only valid respsonses are accepted.

This is unlike command injection. Command Injection is an attack which is designed to execute commands on the PHP hosted system (server). This can be done where most parameters are passed (headers, input boxes, etc) and will typically display any output on the returned webpage.

For example, to return a password for a certain user, you could use a command like:

Typically, to prevent such commands from executing, a whitelist of command can be made, whereby only those listed are allowed to be executed on the server. Alternativly, it is recommend where the application needs to invoke system side commands, to do this through local python scripts, rather then PHP calling the commands.

CRLF injection

CRLF injection comes from the elements CR (Carriage Return) and LF (Line Feed) – together (CRLF) this denotes a new line (done simply by pressing the enter button). If a website for example, allows you to upload a file, an attacker may name this file as follows:

This would result in a system command being carried out to delete everything in the /bin folder.

It also allows an attacker to write to the log file, by creating it own new line. If the logs are configured in such a way that they will email out any WARNINGS or ERRORS, an attacker may add these to a new log line repetitively, backing up the email and bandwidth.

The simple way around this is for JAVA to sanitise any input strings, either through substituting known commands, or through methods such as

SQL Injection

.NET SQL Injection allows an authorised SQL command to be sent to the SQL server and executed.

An SQL string may be built using inputs from a form. A possible example of this is:

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'formemail';

where the red is the text from an input field.

However, we can modify this string which can allow some malicious stuff to happen:

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'formemail'; DROP DATABASE members --';

Adding the red text to the email input box, would allow us to delete the whole table, or alternatively insert a new record into a table, or possible delete records, modify records (change passwords), or even delete whole tables.

To prevent this, you can limit the damage an SQL injection can do you using proper database permissions (deleting records, tables, etc), and to also use good sanitisation – look for -- or ; in any field and invalidate the data if it has these characters.

Directory Traversal

Directory traversal can also be referred to as a “dot dot slash” attack.

In php, a resource (page) can be called as follows:

However, it may be possible to get other files, not even part of the web directory using the following examples:

The easiest way to prevent this is to assign proper permission on the server itself. However, many web developers do not own the server, therefore, another layer of protection is fully qualify the file path, with the root being where the webpage sits.

Connection String Injection

Also known as connection string pollution, it is possible for an attacker to inject parameters into a connection string to a database. Typically a connection string is built by delimiting each value with a comma. In an injection attack, strings can be built using semi colons as a delimiter.

A typical connection string to a windows SQL server may look like the following:

Data source = SQL2005; initial catalog = db1; integrated security=no; user id=+’User_Value’+; Password=+’Password_Value’+;

However, if an attacker places a rouge windows SQL server on the internet, and then uses a connection string like follows:

Data source = SQL2005; initial catalog = db1; integrated security=no; user id=;Data Source=Rogue Server; Password=; Integrated Security=true;

This allows the target windows SQL server to connect to the rouge server using its own Windows credentials, exposing much data.

Backdoors

Backdoors can be common within applications and web applications and can occur across many types of frameworks, however, it’s the security around the knowledge of backdoors, and what they allow, which can be of concern. All modems, routers and some managed network infrastructure have administrator usernames and passwords. However, sometimes, the network vendor (CISCO, NETGEAR, etc) or ISP may choose to put a backdoor access onto these devices. This may be in case a user forgets their administrator credentials, for automatic firmware updates, or for remote troubleshooting. Some of these backdoors may allow for more settings then what is normally shown to an end user.

For example, some older Optus supplied modems had the hidden user: Admin, and a password of: Y3S0ptus. This was standard across thousands of supplied modems. The problem was, the end user had no way of changing the default setting for remote web access from Enabled to Disabled, which meant anyone that knew of their IP address or domain name, could now remote access their modem router, add port redirects, and now connect to devices within their LAN.

In the case of ISP provided modems, it might be safer to simply by something else, not supplied by the ISP.