PHP Security Mini Guide – Directory Traversal & Code Injection

Directory Traversal

Directory Traversal refers to the attack in which an authenticated or unauthenticated user can request and view or execute files which reside outside the root directory of a web application, or outside a directory in which they should be restricted to. This results in an attacker being able to read any file which the user running the webserver (commonly www-data) has access to. If a server has misconfigured file permissions (very common), then this attack can be further escalated.

In the following example the script passes an unavalidated/unsanitized value directly to the include() function. This means that the script will try to include whatever path/filename is passed as a parameter:

Insecure code sample:

$file = $_GET['file'];
include($file);

For example, passing /etc/passwd which is a file readable by all the users returns the content of the file which contains information of all users on the system:

PHP Security

This vulnerability can be mitigated in different ways depending on the case. However the most common and generic way to do it is by using the basename() and realpath() functions.

The basename() function returns only the filename in a given path/filename:

Input: ../../../etc/passwd
Output: passwd

The realname() function returns the canonicalized absolute pathname, only if the file exists and if the running script has executable permissions on all directories in the hierarchy.

Input: ../../../etc/passwd
Output: /etc/passwd

Secure code sample:

$file = basename(realpath($_GET['file']));
include($file);

Now when we request the same file we get an empty response:

PHP security

Avoid blacklisting

Blacklisting is often a bad practice simply because there are more than one ways to make the same request and hackers will always find ways to bypass restrictions. For example ../../../etc/ can also be written as ..%2F..%2F..%2Fetc%2F. If you need to specify access to specific files use a whitelist.

Code Injection/Execution

In this vulnerability an attacker maliciously takes advantage of a script which contains system functions/calls, to read or execute files on a remote server. This is synonymous to having a backdoor shell. Needless to say that under certain circumstances privilege escalation is possible.

In this example a script is using the exec() function to execute the ping command. However, the host is dynamic as it is being passed via an HTTP GET request:

Insecure code sample:

exec("ping -c 4 " . $_GET['host'], $output);
echo "<pre>";
print_r($output);
echo "</pre>";

Passing http://www.google.com as an example, returns the output of the ping command:

PHP Security

This is vulnerable to code injection as it allows the user to pass multiple commands to the function by simply using the “;” delimiter character which in linux can be used to execute multiple commands inline. For example, passing the following value “http://www.google.com;whoami” in the host parameter returns:

PHP Security

As we can see, the script executed both the ping and whoami command.

PHP has two functions, escapeshellarg() and escapeshellcmd(), which can help harden functions such as exec(), shell_exec(), passthru() and system().

escapeshellcmd() escapes any characters in a string that might be used to execute arbitrary commands. The following characters are escaped by preceding a backslash before them &#;`|*?~<>^()[]{}$\, \x0A and \xFF. Single and double quotes are escaped only if they are not paired.

Input: ping -c 4 www.google.com;ls -lah
Output: ping -c 4 www.google.com\;ls -lah

escapeshellarg() adds single quotes around a string and escapes any existing single quotes so that the entire string is being passed as a single argument to a shell command.

Secure code sample:

// #1 Restrict multiple commands
exec(escapeshellcmd("ping -c 4 " . $_GET['host']), $output);

// #2 Restrict multiple commands and multiple arguments
exec(escapeshellcmd("ping -c 4 " . escapeshellarg($_GET['host'])), $output);

The script does not execute the invalid input:

PHP Security

In addition to using these functions, a whitelist of accepted commands/arguments can be created. It should be noted that the escapeshellcmd() and escapeshellarg() functions might behave unpredictably on different Operating Systems, especially on Windows.

Unless it is necessary to keep, it is highly recommended to not use and disable these functions in PHP configurations to avoid security issues.

https://www.acunetix.com/websitesecurity/php-security-2/

Advertisements

Scan Password WordPress dengan tools wpscan

wpscan11

siapa yang tak kenal wordpress.. banyak tentunya…

namun bagi yang kenal web wordpress dan menggunakan wordpress untuk website instansi perusahaanya anda harus hati-hati mengenai keamanannya, karena wp ini masih rentan keamanannya.

jangan terlalu yakin aman. karena tidak ada jaminan dari sananya, apalaagi anda dapatkann gratis, atau anda menjualkannya lagi mungkin untuk bisnis web dengan gampang untuk mendapatkan uang dan klien masih awam dan tak mempermasalahkannya. itu tak jadi masalah.

saya juga pake wp untuk blog disini. gratis.

agar keamanan wp anda teruji. cobalah tools yang bernama wpscan untuk mengujinya.

wpscan alat untuk mengintip versi WordPress sebuah website. Tidak sebatas itu, dia bahkan bisa digunakan untuk melihat celah dari suatu plugin / theme yang digunakan website anda. Manakah yang rentan dan memungkinkan disusupi hacker.

untuk penjelasan lebih lanjut silahkan searching di googl.e. wassalam.

 

 

PHP Input Validation , Web Security

Input Validation is the outer defensive perimeter for your web application. This perimeter protects the core business logic, processing and output generation. Beyond the perimeter is everything considered potential enemy territory which is…literally everything other than the literal code executed by the current request. All possible entrances and exits on the perimeter are guarded day and night by trigger happy sentries who prefer to shoot first and never ask questions. Connected to this perimeter are separately guarded (and very suspicious looking) “allies” including the Model/Database and Filesystem. Nobody wants to shoot them but if they press their luck…pop. Each of these allies have their own perimeters which may or may not trust ours.

Remember what I said about who to trust? As noted in the Introduction, we trust nothing and nobody. The common phrase you will have seen in PHP is to never trust “user input”. This is one of those compartmentalising by trust value issues I mentioned. In suggesting that users are untrusted, we imply that everything else is trusted. This is untrue. Users are just the most obvious untrusted source of input since they are known strangers over which we have no control.

Validation Considerations

Input validation is both the most fundamental defense that a web application relies upon and the most unreliable. A significant majority of web application vulnerabilities arise from a validation failure, so getting this part of our defenses right is essential. Even where we do appear to have gotten it down, we’ll need to be concious of the following considerations.

You should bear these in mind whenever implementing custom validators or adopting a 3rd party validation library. When it comes to 3rd party validators, also consider that these tend to be general in nature and most likely omit key specific validation routines your web application will require. As with any security oriented library, be sure to personally review your preferred library for flaws and limitations. It’s also worth bearing in mind that PHP is not above some bizarre arguably unsafe behaviours. Consider the following example from PHP’s filter functions:

filter_var('php://', FILTER_VALIDATE_URL);

The above example passes the filter without issue. The problem with accepting a php:// URL is that it can be passed to PHP functions which expect to retrieve a remote HTTP URL and not to return data from executing PHP (via the PHP wrapper). The flaw in the above is that the filter options have no method of limiting the URI scheme allowed and users’ expect this to be one of http, https or mailto rather than some generic PHP specific URI. This is the sort of generic validation approach we should seek to avoid at all costs.

Be Wary Of Context

Validating input is intended to prevent the entry of unsafe data into the web application. It has a significant stumbling block in that validation is usually performed to check if data is safe for its first intended use.

For example, if I receive a piece of data containing a name, I may validate it fairly loosely to allow for apostrophes, commas, brackets, spaces, and the whole range of alphanumeric Unicode characters (not all of which need literally be alphabetic according to Western languages). As a name, we’d have valid data which can be useful for display purposes (it’s first intended use). However, if we use that data elsewhere (e.g. a database query) we will be putting it into a new context. In that new context, some of the characters we allow would still be dangerous – our name might actually be a carefully crafted string intended to perform an SQL Injection attack.

The outcome of this is that input validation is inherently unreliable. Input validation works best with extremely restricted values, e.g. when something must be an integer, or an alphanumeric string, or a HTTP URL. Such limited formats and values are least likely to pose a threat if properly validated. Other values such as unrestricted text, GET/POST arrays, and HTML are both harder to validate and far more likely to contain malicious data.

Since our application will spend much of its time transporting data between contexts, we can’t just validate all input and call it a day. Input validation is our initial defense but never our only one.

One of the most common partner defenses used with Input Validation is Escaping (also referred to as Encoding). Escaping is a process whereby data is rendered safe for each new context it enters. While Escaping is usually associated with Cross-Site Scripting, it’s also required in many other places where it might be referred to as Filtering instead. Nobody said security terminology was supposed to be consistent, did they?

Besides Escaping, which is output oriented to prevent misinterpretation by the receiver, as data enters a new context it should often be greeted by yet another round of context-specific validation.

While often perceived as duplication of first-entry validation, additional rounds of input validation are more aware of the current context where validation requirements may differ drastically from the initial round. For example, input into a form might include a percentage integer. At first-entry, we will validate that it is indeed an integer. However, once passed to our application’s Model, a new requirement might emerge – the percentage needs to be within a specific range, something only the Model is aware of since the range is a product of the applications business logic. Failing to revalidate in the new context could have some seriously bad outcomes.

Never Blacklist; Only Whitelist

The two primary approaches to validating an input are whitelisting and blacklisting. Blacklisting involves checking if the input contains unacceptable data while whitelisting checks if the input contains acceptable data. The reason we prefer whitelisting is that it produces a validation routine that only passes data we expect. Blacklisting, on the other hand, relies on programmers anticipating all possible unexpected data which means it is far easier to run afoul of omissions and errors.

A good example here is any validation routine designed to make HTML safe for unescaped output in a template. If we take the blacklisting approach, we need to check that the HTML does not contain dangerous elements, attributes, styles and executable javascript. That accumulates to a large amount of work and all blacklisting oriented HTML sanitisers nearly always tend to forget or omit some dangerous combination of markup. A whitelist based HTML sanitiser dispenses with this uncertainty by only allowing known safe elements and attributes. All other elements and attributes will be stripped out, escaped or deleted regardless of what they are.

Since whitelisting tends to be both safer and more robust, it should be preferred for any validation routine.

Never Attempt To Fix Input

Input validation is frequently accompanied by a related process we call Filtering. Where validation just checks if data is valid (giving either a positive or negative result), Filtering changes the data being validated to meet the validation rules being applied.

In many cases, there’s little harm in doing this. Common filters might include stripping all but integers out of a telephone number (which may contain extraneous brackets and hyphens), or trimming data of any unneeded horizontal or vertical space. Such use cases are concerned with minimal cleanup of the input to eliminate transcription or transmission type errors. However, it’s possible to take Filtering too far into the territory of using Filtering to block the impact of malicious data.

One outcome of attempting to fix input is that an attacker may predict the impact your fixes have. For example, let’s say a specific string in an input is unacceptable – so you search for it, remove it, and end the filter. What if the attacker created a split string deliberately intended to outwit you?

<scr<script>ipt>alert(document.cookie);</scr<script>ipt>

In the above example, naive filtering for a specific tag would achieve nothing since removing the obvious <script> tag actually ensures that the remaining text is now a completely valid HTML script element. The same principle applies to the filtering of any specific format and it underlines also why Input Validation isn’t the end of your application’s defenses.

Rather than attempting to fix input, you should just apply a relevant whitelist validator and reject such inputs – denying them any entry into the web application. Where you must filter, always filter before validation and never after.

Never Trust External Validation Controls But Do Monitor Breaches

In the section on context, I noted that validation should occur whenever data moves into a new context. This applies to validation processes which occur outside of the web application itself. Such controls may include validation or other constraints applied to a HTML form in a browser. Consider the following HTML5 form (labels omitted).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<form method="post" name="signup">
    <input name="fname" placeholder="First Name" required />
    <input name="lname" placeholder="Last Name" required />
    <input type="email" name="email" placeholder="someone@example.com" required />
    <input type="url" name="website" required />
    <input name="birthday" type="date" pattern="^d{1,2}/d{1,2}/d{2}$" />
    <select name="country" required>
        <option>Rep. Of Ireland</option>
        <option>United Kingdom</option>
    </select>
    <input type="number" size="3" name="countpets" min="0" max="100" value="1" required />
    <textarea name="foundus" maxlength="140"></textarea>
    <input type="submit" name="submit" value="Submit" />
</form>

HTML forms are able to impose constraints on the input used to complete the form. You can restrict choices using a option list, restrict a value using a mininum and maximum allowed number, and set a maximum length for text. HTML5 is even more expressive. Browsers will validate urls and emails, can limit input on date, number and range fields (support for both is sketchy though), and inputs can be validated using a Javascript regular expression included in the pattern attribute.

With all of these controls, it’s important to remember that they are intended to make the user experience more consistent. Any attacker can create a custom form that doesn’t include any of the constraints in your original form markup. They can even just use a programmed HTTP client to automate form submissions!

Another example of external validation controls may be the constraints applied to the response schema of third-party APIs such as Twitter. Twitter is a huge name and it’s tempting to trust them without question. However, since we’re paranoid, we really shouldn’t. If Twitter were ever compromised, their responses may contain unsafe data we did not expect so we really do need to apply our own validation to defend against such a disaster.

Where we are aware of the external validation controls in place, we may, however, monitor them for breaches. For example, if a HTML form imposes a maxlength attribute but we receive input that exceeds that lenght, it may be wise to consider this as an attempted bypass of validation controls by a user. Using such methods, we could log breaches and take further action to discourage a potential attacker through access denial or request rate limiting.

Evade PHP Type Conversion

PHP is not a strongly typed language and most of its functions and operations are therefore not type safe. This can pose serious problems from a security perspective. Validators are particularly vulnerable to this problem when comparing values. For example:

assert(0 == '0ABC'); //returns TRUE
assert(0 == 'ABC'); //returns TRUE (even without starting integer!)
assert(0 === '0ABC'); //returns NULL/issues Warning as a strict comparison

When designing validators, be sure to prefer strict comparisons and use manual type conversion where input or output values might be strings. Web forms, as an example, always return string data so to work with a resulting expected integer from a form you would have to verify its type:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
function checkIntegerRange($int, $min, $max)
{
    if (is_string($int) && !ctype_digit($int)) {
        return false; // contains non digit characters
    }
    if (!is_int((int) $int)) {
        return false; // other non-integer value or exceeds PHP_MAX_INT
    }
    return ($int >= $min && $int <= $max);
}

You should never do this:

1
2
3
4
function checkIntegerRangeTheWrongWay($int, $min, $max)
{
    return ($int >= $min && $int <= $max);
}

If you take the second approach, any string which starts with an integer that falls within the expected range would pass validation.

assert(checkIntegerRange(“6’ OR 1=1”, 5, 10)); //issues NULL/Warning correctly assert(checkIntegerRangeTheWrongWay(“6’ OR 1=1”, 5, 10)); //returns TRUE incorrectly

Type casting naughtiness abounds in many operations and functions such as in_array() which is often used to check if a value exists in an array of valid options.

Data Validation Techniques

Failing to validate input can lead to both security vulnerabilities and data corruption. While we are often preoccupied with the former, corrupt data is damaging in its own right. Below we’ll examine a number of validation techniques with some examples in PHP.

Data Type Check

A Data Type check simply checks whether the data is a string, integer, float, array and so on. Since a lot of data is received through forms, we can’t blindly use PHP functions such as is_int() since a single form value is going to be a string and may exceed the maximum integer value that PHP natively supports anyway. Neither should we get too creative and habitually turn to regular expressions since this may violate the KISS principle we prefer in designing security.

Allowed Characters Check

The Allowed Characters check simply ensures that a string only contains valid characters. The most common approaches use PHP’s ctype functions and regular expressions for more complex cases. The ctype functions are the best choice where only ASCII characters are allowed.

Format Check

Format checks ensure that data matches a specific pattern of allowed characters. Emails, URLs and dates are obvious examples here. Best approaches should use PHP’s filter_var() function, the DateTime class and regular expressions for other formats. The more complex a format is, the more you should lean towards proven format checks or syntax checking tools.

Limit Check

A limit check is designed to test if a value falls within the given range. For example, we may only accept an integer that is greater than 5, or between 0 and 3, or must never be 34. These are all integer limits but a limit check can be applied to string length, file size, image dimensions, date ranges, etc.

Presence Check

The presence check ensures that we don’t proceed using a set of data if it omits a required value. A signup form, for example, might require a username, password and email address with other optional details. The input will be invalid if any required data is missing.

Verification Check

A verification check is when input is required to include two identical values for the purposes of eliminating error. Many signup forms, for example, may require users to type in their requested password twice to avoid any transcription errors. If the two values are identical, the data is valid.

Logic Check

The logic check is basically an error control where we ensure the data received will not provoke an error or exception in the application. For example, we may be substituting a search string received into a regular expression. This might provoke an error on compiling the expression. Integers above a certain size may also cause errors, as can zero when we try the divide using it, or when we encounter the weirdness of +0, 0 and -0.

Resource Existence Check

Resource Existence Checks simply confirms that where data indicates a resource to be used, that the resource actually exists. This is nearly always accompanied by additional checks to prevent the automatic creation of non-existing resources, the diverting of work to invalid resources, and attempts to format any filesystem paths to allow Directory Traversal Attacks.

Validation Of Input Sources

Despite our best efforts, input validation does not solve all our security problems. Indeed, failures to properly validate input are extremely common. This becomes far more likely in the event that the web application is dealing with a perceived “trusted” source of input data such as a local database. There is not much in the way of additional controls we can place over a database but consider the example of a remote web service protected by SSL or TLS, e.g. by requesting information from the API’s endpoints using HTTPS.

HTTPS is a core defense against Man-In-The-Middle (MITM) attacks where an attacker can interject themselves as an intermediary between two parties. As an intermediary, the MITM impersonates a server. Client connections to the server are actually made to the MITM who then makes their own separate connection to the requested server. In this way, a MITM can transfer messages between both parties without their knowledge while still retaining the capacity to read the messages or alter them to the attacker’s benefit before they reach their intended destination. To both the server and client, nothing extraordinary has occurred so long as the data keeps flowing.

To prevent this form of attack, it is necessary to prevent an attacker from impersonating the server and from reading the messages they are exchanging. SSL/TLS perform this task with two basic steps:

  1. Encrypt all data being transmitted using a shared key that only the server and client have access to.
  2. Require that the server prove its identity with a public certificate and a private key that are issued by a trusted Certificate Authority (CA) recognised by the client.

You should be aware that encryption is possible between any two parties using SSL/TLS. In an MITM attack, the client will contact the attacker’s server and both will negotiate to enable mutual encryption of the data they will be exchanging. Encryption by itself is useless in this case because we never challenged the MITM server to prove it was the actual server we wanted to contact. That is why Step 2, while technically optional, is actually completely necessary. The web application MUST verify the identity of the server it contacted in order to defend against MITM attacks.

Due to a widespread perception that encryption prevents MITM attacks, many applications and libraries do not apply Step 2. It’s both a common and easily detected vulnerability in open source software. PHP itself, due to reasons beyond the understanding of mere mortals, disables server verification by default for its own HTTPS wrapper when using stream_socket_client(), fsockopen() or other internal functions. For example:

1
$body = file_get_contents('https://api.example.com/search?q=sphinx');

The above suffers from an obvious MITM vulnerability and any data resulting from such a HTTPS request can never be considered as representing a response from the intended service. This request should have been made by enabling server verification as follows:

1
2
$context = stream_context_create(array('ssl' => array('verify_peer' => TRUE)));
$body = file_get_contents('https://api.example.com/search?q=sphinx', false, $context);

Returning to sanity, the cURL extension does enable server verification out of the box so no option setting is required. However, programmers may demonstrate the following crazy approach to securing their libraries and applications. This one is easy to search for in any libraries your web application will depend on.

curl_setopt(CURLOPT_SSL_VERIFYPEER, false);

Disabling peer verification in either PHP’s SSL context or with curl_setopt() will enable a MITM vulnerability but it’s commonly allowed to deal with annoying errors – the sort of errors that may indicate an MITM attack or that the application is attempting to communicate with a host whose SSL certificate is misconfigured or expired.

Web applications can often behave as a proxy for user actions, e.g. acting as a Twitter Client. The least we can do is hold our applications to the high standards set by browsers who will warn their users and do everything possible to prevent users from reaching suspect servers.

Conclusion

TBD

 

Source : http://phpsecurity.readthedocs.io/en/latest/Input-Validation.html

Membatasi akses terhadap ekstensi file tertentu dengan .htaccess di website

Dalam sebuah website ada sebuah ruang atau folder direktori yang dimana berfungsi sebagai penyimpanan file upload atau file-file aset website selain dari file-file yang berisi kode-kode algoritma atau proses seperti kode php.

Folder tersebut bukan untuk melakukan proses php, hanya untuk memanfaatkan asset-asset web seperti css, image, jss. Untuk melakukan pembatasan akses file salah satu metoda yang bisa diimplementasikan adalah dengan menggunakan setting .htaccess.

Adapun contoh kode untuk membatasi akses untuk selain .php adalah seperti kode berikut ini.

<FilesMatch “\.(?:inc|php|py|rb)$”>
Order allow,deny
Deny from all
</FilesMatch>

Kode diatas tidak akan mengijinkan akses untuk file-file yang memiliki ektensi inc, php, py, rb. File .htaccess tersebut dapat di  simpan pada direktory uploads atau image atau css dan sebagainya. Semoga yang membaca bisa mengambil manfaat dari tulisan ini. Wasslm.

Mengenal Cookies PHP

Cookies dapat dimanfaatkan dalam aktivitas hack sebuah web. Namun, bagi yang masih belum kenal dengan cookies ini, mari kita gali apa itu cookies?

Cookies digunakan untuk menyimpan informasi yang dibutuhkan sebuah website dan ditaruh pada komputer client. Singkatnya Cookies ini hampir sama dengan Session namun tidak disimpan pada server melainkan pada komputer client.

Filter Display Image Dengan File .htaccess

Ketika membuat sebuah web, biasanya terdapat sebuah folder atau direktori yang dibuat khusus untuk menampung file-file yang diupload seperti gambar atau dokumen. Namun, kadang kita ingin membatasi hanya file-file dengan ekstension tertentu yang bisa dipanggil atau di tampilkan di browser, misal hanya gambar yang berformat png saja yang bisa di panggil, sedangkan dengan format seperti jpg, jpeg dll, tidak bisa.

endang-web-htaccess

Untuk melakukan filter tersebut, kita bisa menggunakan file .htaccess.

.
.
.
.

.htaccess, merupakan sebuah file text sederhana(dalam format ascii). Pada umumnya kita bisa menggunakan file .htaccess untuk merubah beberapa konfigurasi untuk mengarahkan pada web server apache.

.
.
.
.

berikut contoh kode file .htaccess, yang dimana file tersebut disimpan dalam folder yang terdapat file-file yang akan kita filter.

order allow,deny
<Files ~ “\.(PNG|png)$”>
allow from all
</Files>

kode diatas berfungsi agar file dengan ekstension png saja yang bisa di panggil atau ditampilkan di browser, ekstension selain dari itu tidak akan tampil. Wassalam.

 

 

 

PHP Security : Shell Injection

Selain sql injection, salah satu jenis serangan lainnya yang perlu di ketahui dan diantisipasi bagi web developer adalah berupa web shell injection. Nah, apa itu Web shell injection ?

Web shell ini merupakan kumpulan script  yang dapat mengeksekusi perintah shell. Setiap web shell bentuknya berbeda-beda tergantung dari web server itu sendiri. Misal, jika web servernya apache maka web shell nya berbentuk script PHP dan bentuk script shell nya dikenal dengan PHP shell injection.

PHP shell injection adalah sebuah tindakan untuk melakukan eksploitasi terhadap celah keamanan sebuah website dengan cara menginjeksi Shell hasil pengkodean bahasa PHP terhadap file yang terdapat pada website tersebut yang memiliki kelemahan ataupun kesalahan pemrograman/pengkodean.

.
.
.
.

web-shell-php-injection

Contoh shell yang sudah jadi dan beredar di dunia maya, diantaranya yaitu :

b374k (indonesia)
dQ99-shell
c99 (rusia)
r57
phpShell
itsecteam-shell
Bypass
safeOver
phpShell
itsecteam-shell
Tyrag-Bypass
c100
ASPx
CMD-aspshell
CWShell-Dumper
CGI-Shell

Cara menjalankan web shell, file tersebut harus di sisipkan terlebih dahulu di web server  dalam direktori target. Salah satu, metode upload file adalah Remote File Inclusion atau dikenal dengan disingkat RFI.

.
.
.
.

Cerita singkat Remote File Inclusion. RFI merupakan metode untuk mengeksploitasi web dengan memanfaatkan file yang sudah ada pada file tersebut untuk mengeksekusi file yang diluar web.

Gambaran contoh sederhananya adalah sebagai berikut. Ada sebuah web yang proses eksekusinya menggunakan satu file yang memanggil file yang lain untuk melengkapinya melalui alamat web, seperti berikut :

http://www.target-web.com/?page=artikel.php

pada alamat diatas, tulisan artikel.php, adalah file php yang akan di masukan kedalam script php untuk di proses. kodenya bisa seperti ini.

<?php
$page=$_GET[“page”];
if($page==””){
include “home.php”;
}
include $page.”.php”;
?>

cerita selanjutnya perintah script php di artikel.php akan di eksekusi di dalam kode tersebut. permasalahan cara diatas adalah memungkinkan orang lain untuk memasukan kode selain artikel.php, isinya bebas.

Teman dari RFI adalah LFI atau Local File Inclusion, yaitu hampir sama dengan RFI, namun bedanya RFI memanfaatkan file diluar web, sedangkan LFI memanfaatkan file yang sudah tersimpan di internal server seperti file sistem  /etc/passwd untuk untuk system operasi linux.

Bagaimana cara untuk melindungi web dari serangan RFI atau LFI ? antisipasi untuk menangkal serang ini diantaranya adalah dengan script yang terupdate, lalu pastikan php.ini register_globals dan allow_url_fopen dinonaktifkan.

.
.
.
.

Setelah berhasil di simpan di direktori server, maka hacker bisa memanggilnya dengan cara mengakses file tersebut melalui browser, contoh pemanggilannya :

http://www.target-web.com/c99.php

http://www.target-web.com/  — alamat domain target

c99.php — file php shell injection

.
.
.
.

terlihat cukup mudah, namun butuh latihan untuk dapat melakukannya.

 

PHP Security : SQL Injection

 

sql-injection

 

SQL Injection, istilah yang sudah tidak asing lagi dikalangan web programmer. Namun tidak ada salahnya di bahas kembali dari nol. Mulai dari Apa itu SQL injection ?

Saya coba cuplik dari web tetangga untuk pengertian ini yang menurut saya mudah dicernanya, isinya kurang lebih berikut.

SQL injection adalah serangan yang memanfaatkan kelalaian dari website yang mengijinkan user untuk menginputkan data tertentu tanpa melakukan filter terhadap malicious character.

Sedangkan yang dimaksud dengan malicious yaitu suatu program yang dapat dieksekusi dan dibuat dengan tujuan untuk merusak sistem komputer, jadi  dapat di katakan kode tersebut bersifat jahat/perusak.

Jadi dengan kata lain, dari definisi diatas sudah dapat dilihat bahwa tujuan seseorang melakukan serangan sql injection ini adalah salah satunya merusak sistem, dan yang menjadi target serangan adalah database sistem.

Cukup berbahaya apabila database tersebut memiliki data-data yang bersifat penting. Hal untuk mengantisipasinya sederhana, mudah saja, lakukan backup database secara rutin, itu !

Motif seseorang melakukan serangan adalah beragam, dari hal yang serius sampai hal yang iseng ada seperti coba-coba atau lagi belajar, bisa jadi ingin kepuasan. wallohualam. Namun, bagi yang coba-coba harus ingat, semua tindakan ada konsekuensinya, catet.

Apa manfaat mempelajari ini? tujuannya belajar sql injection adalah untuk mengetahui dan mengantisipasi serangan dan bukan sebaliknya.

Sampai sini teman-teman mudah-mudahan dapat memahami maksud dari pengertian sql injection ini.

.
.
.
.

Bagaimana cara seseorang melakukannya?
Untuk melakukan sql injection, orang tersebut harus sudah memahami tentang query dan database dan yang berkenaan dengan web (html, php, … dst), kurang lebih seperti itu.

.
.
.
.

Sebagai bentuk contoh sql injection seperti berikut.

Skenarionya adalah untuk menghapus tabel user pada sebuah tabel.

.
.
.
.

Awalnya ada perintah query untuk menampilkan data pada tabel user seperti ini.

select * from user where username = ‘admin’ and password=’admin’;

jika di eksekusi maka akan tampil data dengan username admin.

Namun, apabila kemudian coba di inject sql

‘; drop table user; —

— drop table user untuk menghapus tabel

menjadi seperti dibawah.

select * from user where username = ”; drop table user; — admin’ and password=’admin’;

maka proses yang terjadi adalah tabel user menjadi terhapus, karena ada sisipan sql drop.

… ‘; drop table user; — admin’ …

itu baru sebagian contoh kecil gambaran perintah sql injection.