This time I will tell you what I have done on the topic on session management.
This describes how to analyse a Session Management Schema, with the goal to understand how the Session Management
mechanism has been developed and if it is possible to break it to bypass the user session. It explains how to test the
security of session tokens issued to the client's browser: how to reverse engineer a cookie, and how to manipulate cookies
to hijack a session.
The following are the steps I have done :
1. Session Management-001
- open browser
- on the browser, click edit => Preferences => Advanced => Network => Setting => on the manual proxy configuration, use 127.0.0.1 as HTTP proxy and use 8008 as port.
- open webscarab
- and then let's browsing, webscarab will be show :
2. Session management-002
Cookies are often a key attack vector for malicious users (typically, targeting other users) and, as such, the application
should always take due diligence to protect cookies. In this section, we will look at how an application can take the
necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.
HTTP/1.1 301 Moved Permanently
Date: Tue, 07 Jun 2011 09:46:03 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.5
Set-Cookie: 69cb2eb0a19889c0e172765110b05475=q2nd3ljmtepbn2tvhhroj4sqj7; 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
3. Session Management-003
When an application does not renew the cookie after a successful user authentication, it could be possible to find a session
fixation vulnerability and force a user to utilize a cookie known to the attacker.
black box testing using webscreb i was found like this below
GET http://www.akakom.ac.id:80/? HTTP/1.1
Host: www.akakom.ac.id
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Cookie: akakom_tpl=akakom;
69cb2eb0a19889c0e172765110b05475=ujpkrlda8l3rpm3qh3127t7i07
DNT: 1
GET http://www.akakom.ac.id:80/components/com_jcomments/js/jcomments-v2.1.js?v=2
HTTP/1.1
Host: www.akakom.ac.id
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://www.akakom.ac.id/
Cookie: akakom_tpl=akakom;
69cb2eb0a19889c0e172765110b05475=ujpkrlda8l3rpm3qh3127t7i07
DNT: 1
If-Modified-Since: Thu, 21 Apr 2011 08:39:28 GMT
If-None-Match: "58e206-6a2b-ade5d000"
GET http://www.akakom.ac.id:80/plugins/system/jcemediabox/js/mediaobject.js?v=101
HTTP/1.1
Host: www.akakom.ac.id
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://www.akakom.ac.id/
Cookie: akakom_tpl=akakom;
69cb2eb0a19889c0e172765110b05475=ujpkrlda8l3rpm3qh3127t7i07
DNT: 1
If-Modified-Since: Thu, 21 Apr 2011 08:33:04 GMT
If-None-Match: "55602a-fdb-97027000"
GET http://www.akakom.ac.id:80/plugins/system/jcemediabox/css/jcemediabox.css?v=101
HTTP/1.1
Host: www.akakom.ac.id
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://www.akakom.ac.id/
Cookie: akakom_tpl=akakom;
69cb2eb0a19889c0e172765110b05475=ujpkrlda8l3rpm3qh3127t7i07
DNT: 1
If-Modified-Since: Thu, 21 Apr 2011 08:33:06 GMT
If-None-Match: "556087-d49-9720f480"
GET http://www.akakom.ac.id:80/components/com_jcomments/tpl/default/style.css?v=10
HTTP/1.1
Host: www.akakom.ac.id
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://www.akakom.ac.id/
Cookie: akakom_tpl=akakom;
69cb2eb0a19889c0e172765110b05475=ujpkrlda8l3rpm3qh3127t7i07
DNT: 1
If-Modified-Since: Thu, 21 Apr 2011 08:39:32 GMT
If-None-Match: "58e281-368d-ae22d900"
GET http://www.akakom.ac.id:80/index.php/component/option,com_jbolo/format,raw/view,js/
HTTP/1.1
Host: www.akakom.ac.id
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://www.akakom.ac.id/
Cookie: akakom_tpl=akakom;
69cb2eb0a19889c0e172765110b05475=ujpkrlda8l3rpm3qh3127t7i07
DNT: 1
GET http://www.akakom.ac.id:80/plugins/system/jcemediabox/themes/standard/css/style.css?version=101 HTTP/1.1
Host: www.akakom.ac.id
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://www.akakom.ac.id/
Cookie: akakom_tpl=akakom;
69cb2eb0a19889c0e172765110b05475=ujpkrlda8l3rpm3qh3127t7i07
DNT: 1
If-Modified-Since: Thu, 21 Apr 2011 08:33:06 GMT
If-None-Match: "556075-123a-9720f480"
now go to the webscreb lite and you would fount an interface like this
DNT: 1
after that i tried to view login script on akakom.ac.id like this
you can try with the other same to see script or conversation like are below :
4. Session Management-004
Session Tokens represent confidential information because they tie the user identity with his own session. It's possible to
test if the session token is exposed to this vulnerability and try to create a replay session attack.
5. Session Management-005
Cross Site Request Forgery describes a way to force an unknowing user to execute unwanted actions on a web application
in which he is currently authenticated. This section describes how to test an application to find this kind of vulnerability.
Authorization is the concept of allowing access to resources only to those permitted to use them. Testing for Authorization
means understanding how the authorization process works, and using that information to circumvent the authorization
mechanism. Authorization is a process that comes after a successful authentication, so the tester will verify this point after
he holds valid credentials, associated with a well-defined set of roles and privileges. During this kind of assessment, it
should be verified if it is possible to bypass the authorization schema, find a path traversal vulnerability, or find ways to
escalate the privileges assigned to the tester.
The following are the steps I have done :
1. Authorization Testing-001
First, we test if it is possible to find a way to execute a path traversal attack and access reserved information.
2. Authorization Testing-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.
type in url https://www.akakom.ac.id/admin/addUser.jsp
3. Authorization Testing-003
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.
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.
The following are the steps I have done :
1. Business Logic Testing-001
No comments:
Post a Comment