Uncl3 Blog's: June 2011

Manusia Tak Sempurna

Subnetting is 32 bit binary numbers it can use to differentiate betwen network ID and host ID. It can be represent the location host, on local network or external network.

We often see in writing the ip address/computer addressing as follows 192.168.0.1/24.

/ 24 indicatesthat the network connection is divided into 256 or 254 client computers with an id and a host,subnet mask is 255.255.255.0 for this group and in this workgroup can be formed onlyone group that is only a start xxx.xxx.xxx.0 - xxx.xxx.xxx.256.

0 comments | |

Bypass Client Side JS

Manusia Tak Sempurna

CASE

This website performs both client and server side validation. For this exercise, your job is to break the client side validation and send the website input that it wasn't expecting. You must break all 7 validators at the same time.

picture

I try to input

picture

but it seems not succes it just make appear pop up

picture

so I try with burpsuite to change the variable on the box

picture

box 1

I just add ABC

box 2

I just add 456

box 3

I just add !@#

box 4

I just add 7

box 5

I just add 12345

box 6

I just add 1234567

box 7

I just add 9876

after I change the variable on the box then it's work. It can bypass on the client side.

picture

0 comments | |

Install WebGoat

Manusia Tak Sempurna

Before we install WebGoat we need java you can download it in here
and if you want to download WebGoat you can download in here
After that you can extract the file with terminal

p7zip -d WebGoat-OWASP_Standard-5.3_RC1.7z

if you don't have p7zip you can download from terminal

apt-get install p7zip

Then if you want to make your dekstop clean you can move it inside /pentest/web/webgoat you can do it form terminal

mkdir /pentest/web/webgoat
mv WebGoat-5.3_RC1/* /pentest/web/webgoat

now make /pentest/web/webgoat/webgoat.sh executable with

chmod +x /pentest/web/webgoat/webgoat.sh

Now you can run webgoat on port 80 or 8080 running

sh /pentest/web/webgoat/webgoat.sh start80 or sh /pentest/web/webgoat/webgoat.sh start8080

and to stop tomcat and webgoat use

sh /pentest/web/webgoat/webgoat.sh stop

Open up firefox and connect to http://127.0.0.1/webgoat/attack or http://127.0.0.1:8080/webgoat/attack according to the port you use to run tomcat.

username : guest
password : guest

after that you can use WebGoat

0 comments | |

Damn Vulnerable Web App (DVWA)

Manusia Tak Sempurna

DVWA is to practice or learn the vulnerablity web. In this application include :
Brute Force
Command Execution
CSRF
File Inclusion
SQL Injection
SQL Injection Blind
Upload
XSS Reflected
XSS Stored

XSS Reflected
I just try to XSS level low with this script :
<script>alert("XSS LOW")</script>
and the result is like in this picture

And then the next level is medium
In this level I just try with this script
<script language=javascript>alert("XSS Medium");</script>
and the result is like in the picture

The next level is high level
On this level I can't get the right script so I can't solved this level

Labels: DVWA 1 comments | |

XSS Persistent and XSS Non - Persistent

Manusia Tak Sempurna

XSS Non - Persistent

The non-persistent(or reflected) cross-site scripting vulnerability is by far the most common type.These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.

A third-party attacker may easily place hidden frames or deceptive links to unrelated sites. They can cause victims' browsers to navigate to URLs on the vulnerable site automatically, say, to pick up their contact information—often completely in the background—and in such a case, the attacker can intrude into the security context that rightfully belonged to the victim.

XSS Persistent

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

For example, say the Golden Orchid is a dating website. Members scan the profiles of other members if they look interesting. Meanwhile, everybody's real names and email are kept secret on the server. The only time a member's real name and email are in the browser are when the member is signed in, and they can't see anybody else's.

Say, a hacker Mallory is a member, and he wants to figure out the real names of the women he sees on the site. To do so, he writes a program that runs on the women's browsers when they visit hisprofile. It knows where to get the real name and info, because Mallory read how the Golden Orchid web pages work. It then sends a quick message to his own server, which collects all of this information while he's watching football.

To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal) but the text at the end of his answer is his program to steal names and emails. If it's enclosed in a <script> element, it won't show on the screen, it'll just run the program instead. So Alice is a member, sees the listing for Mallory. When she gets to the page with his answer to the First Date question, Mallory's program runs, steals a copy of Alice's real name, real email, address, and possibly even her password, directly from her machine, while she's visiting the dating website, and she never notices because there's very little to notice.

Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.

The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, etc.) that can be controlled by an attacker could become an injection vector.

Labels: Security 0 comments | |

WEB SERVICES TESTING

Manusia Tak Sempurna

1. WS Information Gathering
The first step to perform a Web Service Test is to determine the WS entry points and the communication schema: this is
described in the WSDL associated with the WS.

2. Testing WSDL
Check the WSDL of the web service to find the entry points and try to invoke an operation that is not used in a standard SOAP Request. Ensure that the WS doesn’t give some confidential information

3. XML Structural Testing
This section discusses the types of attack vectors one could send to a web service in an attempt to assess its reaction to malformed or maliciously-crafted messages. For example, elements which contain large numbers of attributes can cause problems with parsers. This category of attack also includes XML documents which are not well-formed XML (e.g., with overlapping elements, or with open tags that have no matching close tags). DOM-based parsing can be vulnerable to DoS due to the fact that the complete message is loaded into memory (as opposed to SAX parsing). For example, oversized attachments can cause an issue with DOM architectures.

4. XML Content-level Testing
Content-level attacks target the server hosting a web service and any applications that are utilized by the service, including web servers, databases, application servers, operating systems, etc. Content-level attack vectors include
1) SQL Injection or XPath injection
2) Buffer Overflow and
3) Command Injection.

5. HTTP GET parameters/REST Testing
Many XML applications are invoked by passing them parameters using HTTP GET queries. These are sometimes known as
“REST-style" Web Services (REST = Representational State Transfer). These Web Services can be attacked by passing
malicious content on the HTTP GET string (e.g. extra long parameters (2048 chars), SQL statements/injection (or OS
Injection parameters).

6. Naughty SOAP attachments
This section describes attack vectors for Web Services that accept attachments. The danger exists in the processing of the attachment on the server and redistribution of the file to clients.

7. Replay Testing
This section describes testing replay vulnerabilities of a web service. The threat for a replay attack is that the attacker can assume the identity of a valid user and commit some nefarious act without detection

Labels: OWASP 0 comments | |

AJAX TESTING

Manusia Tak Sempurna

1. AJAX Vulnerabilities
Asynchronous Javascript and XML (AJAX) is one of the latest techniques used by web application developers to provide a user experience similar to that of a local application. Since AJAX is still a new technology, there are many security issues that have not yet been fully researched. Some of the security issues in AJAX include:
• Increased attack surface with many more inputs to secure
• Exposed internal functions of the application
• Client access to third-party resources with no built-in security and encoding mechanisms
• Failure to protect authentication information and sessions
• Blurred line between client-side and server-side code, resulting in security mistakes
2. How to test AJAx
Because most attacks against AJAX applications are analogs of attacks against traditional web applications, testers should refer to other sections of the testing guide to look for specific parameter manipulations to use in order to discover vulnerabilities. The challenge with AJAX-enabled applications is often finding the endpoints that are the targets for the asynchronous calls and then determining the proper format for requests.

Labels: OWASP 0 comments | |

DENIAL OF SERVICE TESTING

Manusia Tak Sempurna

1. Testing for SQL Wildcard_Attacks
2. D Locking Customer Accounts
In this test we check whether an attacker can lock valid user accounts by repeatedly attempting to log in with a wrong password.
when we try to login by exist account and wrong password or by not exist account and wrong password we get the following error message:

when we try to register by the axist account we get the following error message:

3. Buffer Overflows
4. User Specified Object Allocation
In this test we check whether it is possible to exhaust server resources by making it allocate a very high number of objects.

Our targets can not be attacked using this method:

5. User Input as a Loop Counter
6. Writing User Provided Data to Disk
With this test, we check that it is not possible to cause a DoS condition by filling the target disks with log data
7. Failure to Release Resources
With this test, we check that the application properly releases resources (files and/or memory) after they have been used.
8. Storing too Much Data in Session
In this test, we check whether it is possible to allocate big amounts of data into a user session object in order to make the server exhaust its memory resources.

Labels: OWASP 0 comments | |

DATA VALIDATION TESTING

Manusia Tak Sempurna

TESTING FOR REFLECTED CROSS SITE SCRIPTING (OWASP-DV-001)

Reflected Cross-site Scripting (XSS) is another name for non-persistent XSS, where the attack doesn’t load with the vulnerable web application but is originated by the victim loading the offending URI. In this article we will see some ways to
test a web application for this kind of vulnerability.

TESTING FOR STORED CROSS SITE SCRIPTING (OWASP-DV-002)

Stored XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application.
This vulnerability can be used to conduct a number of browser-based attacks including:

Hijacking another user’s browser
Capturing sensitive information viewed by application users
Pseudo defacement of the application
Port scanning of internal hosts (“internal” in relation to the users of the web application)
Directed delivery of browser-based exploits
Other malicious activities

TESTING FOR DOM BASED CROSS SITE SCRIPTING (OWASP-DV-003)

The DOM, or Document Object Model is the structural format that may be used to represent documents in the browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security – for example to limit scripts on different domains obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

TESTING FOR CROSS SITE FLASHING (OWASP-DV-004)

ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. ActionScript, like every other language, has some implementation patterns which could lead to security issues.
In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting could be present in flawed Flash applications.

SQL INJECTION (OWASP-DV-005)

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system and, in some cases, issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

LDAP INJECTION (OWASP-DV-006)

LDAP is an acronym for Lightweight Directory Access Protocol. It is a paradigm to store information about users, hosts and many other objects. LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified or inserted.
This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.

ORM INJECTION (OWASP-DV-007)

ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM tool.

XML INJECTION (OWASP-DV-008)

In this section, we describe a practical example of XML Injection: first we define an XML style communication, and we show how it works. Then we describe the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

SSI INJECTION (OWASP-DV-009)

Web servers usually give to the developer the possibility of adding small pieces of dynamic code inside static HTML pages, without having to play with full-fledged server-side or client-side languages. This feature is incarnated by the Server-Side Includes (SSI), a very simple extension that can enable an attacker to inject code into HTML pages, or even perform remote code execution.

XPATH INJECTION (OWASP-DV-010)

XPath is a language that has been designed and developed to operate on data that is described with XML. The XPath injection allows an attacker to inject XPath elements in a query that uses this language. Some of the possible goals are to bypass authentication or access information in an unauthorized manner.

IMAP/SMTP INJECTION (OWASP-DV-011)

This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.

CODE INJECTION (OWASP-DV-012)

This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by
the web server.

OS COMMANDING (OWASP-DV-013)

In this paragraph we describe how to test an application for OS commanding testing: this means try to inject an on command through an HTTP request to the application.

BUFFER OVERFLOW TESTING (OWASP-DV-014)

INCUBATED VULNERABILITY TESTING (OWASP-DV-015)

Also often referred to as persistent attacks, incubated testing is a complex testing that needs more than one data validation vulnerability to work. In this section we describe a set of examples to test an Incubated Vulnerability.

The attack vector needs to be persisted in the first place, it needs to be stored in the persistence layer, and this would only occur if weak data validation was present or the data arrived into the system via another channel such as an admin console or directly via a backend batch process.
Secondly once the attack vector was “recalled” the vector would need to be executed successfully. For example, an incubated XSS attack would require weak output validation so the script would be delivered to the client in its executable form.

TESTING FOR HTTP SPLITTING/SMUGGLING (OWASP-DV-016)

We will analyze two different attacks that target specific HTTP headers: HTTP splitting and HTTP smuggling. The first attack exploits a lack of input sanitization which allows an intruder to insert CR and LF characters into the headers of the
application response and to ‘split’ that answer into two different HTTP messages. The goal of the attack can vary from a cache poisoning to cross site scripting. In the second attack, the attacker exploits the fact that some specially crafted HTTP
messages can be parsed and interpreted in different ways depending on the agent that receives them. HTTP smuggling requires some level of knowledge about the different agents that are handling the HTTP messages (web server, proxy, firewall) and therefore will be included only in the Gray Box testing section

Labels: OWASP 0 comments | |

BUSINESS LOGIC TESTING

Manusia Tak Sempurna

Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional ways. If
an application’s authentication mechanism is developed with the intention of performing steps 1,2,3 in order to
authenticate, what happens if you go from step 1 straight to step 3? In this simplistic example, does the application provide
access by failing open, deny access, or just error out with a 500 message? There are many examples that can be made, but
the one constant lesson is “think outside of conventional wisdom”. This type of vulnerability cannot be detected by a
vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability
is usually one of the hardest to detect, but, at the same time, usually one of the most detrimental to the application, if
exploited.
Business logic may include:

Business rules that express business policy (such as channels, location, logistics, prices, and products); and
Workflows based on the ordered tasks of passing documents or data from one participant (a person or a software system) to another.

Attacks on the business logic of an application are dangerous, difficult to detect, and are usually specific to the application
being tested.

Labels: OWASP 0 comments | |

Cookie and Session

Manusia Tak Sempurna

Understanding Cookies
Cookies are data files written to your hard disk by a Web server computer that is used to identify itself so that users on the site when the user re-visiting the site, the site will be able to recognize it.
Functions of cookies:
1. Helping the web site to "remember" who we are and set the appropriate preferences so that when the user re-visiting this web site will be instantly recognizable.
2. Eliminating the need to re-register on the web site again when accessing the (site only), cookies help the user logged into the web server.
3. Allows web site to browse the web surfing patterns of users and to know your favorite sites are frequently visited.
Types of Cookies
1. Non-persistent (session) cookies. A cookie that will disappear when users close the browser and is usually used on the 'shopping carts' in the online shopping store to browse the items purchased,
2. Persistent cookies. Arranged by portal sites, banner / ad sites and other media who want to know when users return to visit their site. (Eg by providing the option "Remember Me" when logging in). These files are stored on the user's hard drive.
Both types of these cookies store information about a URL or domain name of a user visited the site and several codes indicating what pages you have visited. Cookies may contain personal information of users, such as name and email address, but can also provide information to website users through the registration process. In other words, the cookies will not be able to "steal" the name and email address unless provided by the user. However, there is a specific code (malicious code) that is made for example by an ActiveX control, which can retrieve information from a PC without user's knowledge.
Cookies are generally less than 100 bytes so it will not affect the browsing speed. but because in most cases the browser is set by default to accept cookies then the user will not know that cookies are already on the computer. Cookies can be useful especially on sites that require registration, so each time you visit the site, cookies are going to log a user without having to enter a user name and password again.

Overview of the Session
In general, the session is used to store information between processes a request, whether the request in the form POST or GET. Session is a variable that can maintain its contents within a specified time period (can be set) and stored in server. Although moving the page (in 1 website) variable still survive. So the session is simply a variable with certain characteristics.

PHP has a session (note the activity) that is used to keep / maintain access information from an accessor / user web application. Session tracking allows the user access, application usage by user pangaturan and improve the website services. Each visitor will be given a unique id, called a session id (session_id). This ID can be stored in a cookie on the user side or is included in the URL. Session connection between the client and the server will be lost or broken if the browser is closed. If the browser is run back and connect to the server is then considered a new connection.
One example that illustrates the use of session is the login process. In this case the user will enter a username via the login form. After successful login, the user is faced with the navigation menu links that led to several web pages. when users enter a username it will always appear or are listed on these web pages, then the username must be stored in the session.

Basic Concept Session
Session works just like daycare goods in supermarkets. Buyer came, left luggage, and the officer will provide identification. At the time the buyer will take the goods, the buyer gives the sign on the officers, and officers will be able to take the goods are entrusted with no mixed up with the goods of others. The problem that happens is, how "identification" will be stored on each user accessed the page, so it can be accessed by the system each time a user clicks on a link.

There are three alternatives that can be used to store session data:
• Cookies
• Hidden Form
• Embedding URLs

In general, how the session can be described as When visitors access a page, visitors are starting the session (used in function session_start ()). When the php configuration, session.auto_start is set to 1 then php will conduct sessions start automatically.

Visitors were then given an identity in the form session id, session id is a unique character sets, for example 12345678xx .. Simultaneously, on the server side is also made ses_12345678xx file containing session variables belonging to the visitors. Variables are registered with the function session_register () will be stored in this file.

The method above is the default. But it can determine the location of shelters jug own session variables, such as in a database. When visitors start or continue a session (through session_start ()) then the visitor session id send her to regain her own session variables that have been stored on the server.

Shipping session id to the server could be in 2 ways. The first, which is the default way, transmitted through cookies. PHPSESSID Session id of the cookie (default). There are times when for some reason, visitors to disable cookies (can be done through the browser settings). When this happens, the sending of the session id is done by both, namely through the query string (the string that is added to the URL, like the example at the beginning of the article).

Session will end when the function session_destroy () is called or when the user closes the web browser. From the way the work session earlier, it appears that the key to handle the visitors (on the client side) is just the session id variable, while his other variables on the server. The existence of facilities in the PHP session handling to make the above process becomes simple and easy because PHP do it automatically.

So, the session is of sufficient importance in web-based applications. With the session allows the programmer stores user information in a semi-permanent, meaning that during certain information will be stored. Storage of content resides on a server session variable, so can not be accessed directly by the client.

In web-based application, the session is widely used as an authentication login. With the session allows the programmer to set who can access a page. For example, to view the page in an email mailbox, you must login first. In the login process, among others, will be making a session that will be taken by the user on every page. On the mailbox page, the session is checked. If true then the user session are welcome to open the mailbox page, but if it is wrong then the user can not open the mailbox page, and usually will be asked to log in first. That is why, the user can not access the page directly to your mailbox without logging.

0 comments | |

AUTHORIZATION TESTING

Manusia Tak Sempurna

Testing for Path Traversal (OWASP-AZ-001)

Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read/write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands.

Stage a

Input Vectors Enumeration (a systematic evaluation of each input vector)

Stage b

Testing Techniques (a methodical evaluation of each attack technique used by an attacker to exploit the
vulnerability)

Testing for bypassing authorization schema (OWASP-AZ-002)

This kind of test focuses on verifying how the authorization schema has been implemented for each role/privilege to get access to reserved functions/resources.

Testing for Privilege Escalation (OWASP-AZ-003)

This section describes the issue of escalating privileges from one stage to another. During this phase, the tester should
verify that it is not possible for a user to modify his or her privileges/roles inside the application in ways that could allow
privilege escalation attacks.

Labels: OWASP 0 comments | |

Session Management Testing

Manusia Tak Sempurna

TESTING FOR SESSION MANAGEMENT SCHEMA (OWASP-SM-001)

Method POST

Header Value

Content-Type	multipart/form-data; boundary=d41d8cd98f00b204e9800998ecf8427e
Content-length	38

00000000	2D	2D	64	34	31	64	38	63	64	39	38	66	30	30	62	32	--d41d8cd98f00b2
00000010	30	34	65	39	38	30	30	39	39	38	65	63	66	38	34	32	04e9800998ecf842
00000020	37	65	2D	2D	0D	0A											7e--..

Cokies

akakom_tpl=akakom; __utma=242819602.142294096.1307223034.1307223034.1307430533.2; __utmz=242819602.1307223034.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); 69cb2eb0a19889c0e172765110b05475=8t1prvlodibs737lv6i4tf8st4; __utmb=242819602.1.10.1307430533; __utmc=242819602

Burp Suite

pic 1

pic 2

pic 3

Web Scarab

HTTP/1.1 301 Moved Permanently

Date: Tue, 07 Jun 2011 07:34:06 GMT

Server: Apache/2.2.3 (CentOS)

X-Powered-By: PHP/5.3.5

Set-Cookie: 69cb2eb0a19889c0e172765110b05475=pseoevo6b6n1042tuvdc0gmq13; path=/

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Location:

Content-length: 0

Connection: close

Content-Type: text/html; charset=UTF-8

TESTING FOR COOKIES ATTRIBUTES (OWASP-SM-002)

TESTING FOR SESSION FIXATION (OWASP-SM_003)

found in picture no 1

TESTING FOR EXPOSED SESSION VARIABLES (OWASP-SM-004)

TESTING FOR CSRF (OWASP-SM-005)

Labels: OWASP 0 comments | |

About Me

Labels

Blog Archive

Nine Tail's Blog

LinkedIn

Viewer's

Search

Followers