Source: Hacker

.. that Microsoft might have invented cross site scripting? The term, that is, not the technique.

OWASP 2010 Top 10 (RC1)

The Open Web Application Security Project (OWASP) today released a new top 10 list at its conference in Washington, D.C., that focuses on Web application security risks rather than the way its previous lists highlighted the most common weaknesses found in Websites.

OWASP member Georg Hess says the risk-based focus should broaden the OWASP list’s applicability to IT and higher-level executives, too. “This time, it’s not only about vulnerabilities, but really more about identifying the top 10 risks,” says Hess, CEO and founder of Art of Defence. “This should help raise the importance of this…and make it more likely [for organizations] to understand their risks.”

Injection attacks top the 2010 OWASP Top 10 list of Web application security threats, including SQL, OS, and LDAP injection, followed by cross-site scripting (XSS), broken authentication and session management, insecure direct object references, cross-site request forgery (CSRF), security misconfiguration, failure to restrict URL access, unvalidated redirects and forwards, insecure cryptographic storage, and insufficient transport layer protection.

The list is considered a “release candidate” that will be published in its final form in 2010.

New to the list are security misconfiguration and unvalidated redirects and forwards. Security misconfiguration is prevalent today, as is unvalidated redirects and forwards. “The evidence shows that this relatively unknown issue is widespread and can cause significant damage,” says the OWASP report. Web redirects typically steer users to other pages and sites, and when the data for the destination pages isn’t properly validated, users can be redirected to phishing or malware sites by attackers.

Malicious file execution and information leakage/improper error-handling are no longer on the top 10 list. OWASP says that while malicious file execution is still a big problem in many environments and was especially high in 2007 with PHP vulnerabilities, now that PHP ships with default security, it’s less of a problem. While information leakage/improper error-handling are rampant vulnerabilities, the impact of them isn’t usually as critical.

The OWASP report also includes how to assess the possibility that your Web application would be at risk of these types of Web attacks, as well as mitigation tips. OWASP used its risk-rating methodology to come up with its new list.

The top 10 comes on the heels of WhiteHat Security’s report yesterday of the most common vulnerabilities discovered in its clients’ Websites. In that list, XSS was No. 1 and SQL injection No 5. But Jeremiah Grossman, founder and CTO of WhiteHat, says SQL injection flaw finds were likely underreported. SQL injection flaws can be difficult to detect in scans because developers who disable verbose error messages as a way to protect against SQL injection attack can also inadvertently make it difficult to find SQL injection flaws, according to Grossman.

OWASP 2010 RC1: http://www.owasp.org/index.php/File:OWASP_T10_-_2010_rc1.pdf
Source:

http://darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=221700095&cid=ref-true

http://www.cgisecurity.com/2009/11/owasp-issues-2010-top-10-rc1.html

Moth

Moth is a VMware image with a set of vulnerable Web Applications and scripts, that you may use for:

1. Testing Web Application Security Scanners
2. Testing Static Code Analysis tools (SCA)
3. Giving an introductory course to Web Application Security

The main objective of this tool is to give the community a ready to use testbed for web application security tools. For almost every web application vulnerability that exists in the wild, there is a test script available in moth.

There are three different ways to access the web applications and vulnerable scripts included in moth:

1. Directly
2. Through mod_security
3. Through PHP-IDS (only if the web application is written in PHP)

Both mod_security and PHP-IDS have their default configurations and they show a log of the offending request when one is found. This is very useful for testing web application scanners, and teaching students how web application firewalls work. The beauty is that a user may access the same vulnerable script using the three methods; which helps a lot in the learning process.

Moth image: http://sourceforge.net/projects/w3af/files/moth/moth/moth-v0.6.7z/download

Source:

http://www.bonsai-sec.com/en/research/moth.php

http://www.bonsai-sec.com/blog/index.php/moth-vulnerable-vmware-image/

Enter Samurai

As live CD’s have become more popular, specialized distributions have begun to emerge. One such specialty live CD is Samurai, a distribution squarely focused on web application penetration and vulnerability testing. Samurai is dubbed a “web testing framework” in much the same way that Metasploit is termed a framework. Samurai is sponsored by IntelGuardians Network Intelligence Inc a for profit information security consulting firm based in Washington, DC.

Samurai focuses on tools needed by web application testers to look for common vulnerabilities, such as misconfigurations, cross site scripting (XSS), SQL injection, remote file inclusion and other common vulnerabilities. the CD includes several tools to reconnoiter web applications and servers, enumerate files and directories, and test scripts.

Samurai – First Looks

The bootable Samurai CD allows several options once started. It can be run as a live CD or you can install the framework as a complete operating system:

The starting status screen is fairly clean:

Once you boot Samurai to the login screen you enter the username ’samurai’ and the password ’samurai’ to log in. This information is a little obscure. It appears on the Samurai SourceForge.net project page, and in the Readme.txt that is only available once you’re logged in to the distro:

Once logged in it becomes obvious that Samurai is based on Ubuntu, which is a little unusual for a live CD distribution:

Applications

Samurai comes with a host of useful applications. These include many of the regular Linux tools but also include:

• Burp Suite, a web application attacking tool
• DirBuster, an application file and directory enumeration and brute forcing tool from OWASP
• Fierce Domain Scanner a target ennumeration utility
• Gooscan an automated Google querying tool that is useful for finding CGI vulnerabilities without scanning the target directly, but rather querying Google’s caches
• Grendel-Scan, just released, an open source web application vulnerability testing tool
• HTTP_Print a web server fingerprinting tool
• Maltego CE, an open source intelligence and forensics application that does data mining to find information from the internet and link it together (great for background research on a target).
• Nikto, an open source web server scanner
• Paros, one of my favorite, Java based, cross platform, web application auditing and proxy tools
• Rat Proxy, a semi-automated, passive web application security audit tool.
• Spike Proxy, an extensible web application analyzer and vulnerability scanner.
• SQLBrute, a SQL injection and brute forcing tool.
• w3af (and the GUI), a web application attack and audit framework.
• Wapiti, a web application security auditor and vulnerability scanner
• WebScarab, an HTTP application auditing tool from OWASP
• WebShag, a web server auditing tool
• ZenMap, a NMAP graphical front end

Additionally Samurai includes several utilities that aren’t available from the GUI menu. These include:

• dnswalk, a DNS query and zone transfer tool
• httping, a ping like utility for HTTP requests
• httrack, a website copying utility.
• john the ripper, a password cracking program
• netcat, a TCIP/IP swiss army knife
• nmap, a port scanner and OS detection tool
• siege, an HTTP stress tester and benchmarking tool.
• snarf, a lightweight URL fetching utility

and many others. Of course, all of these tools could easily be installed on your own Linux based machine, but having a live CD with the tools installed and pre configured is quite nice. Samurai also comes with Wine installed, which is handy if you want to run some windows based tools off of the distribution.

Source: http://www.madirish.net/?article=218

Enter Samurai

As live CD’s have become more popular, specialized distributions have begun to emerge. One such specialty live CD is Samurai, a distribution squarely focused on web application penetration and vulnerability testing. Samurai is dubbed a “web testing framework” in much the same way that Metasploit is termed a framework. Samurai is sponsored by IntelGuardians Network Intelligence Inc a for profit information security consulting firm based in Washington, DC.

Samurai focuses on tools needed by web application testers to look for common vulnerabilities, such as misconfigurations, cross site scripting (XSS), SQL injection, remote file inclusion and other common vulnerabilities. the CD includes several tools to reconnoiter web applications and servers, enumerate files and directories, and test scripts.

Samurai – First Looks

The bootable Samurai CD allows several options once started. It can be run as a live CD or you can install the framework as a complete operating system:

The starting status screen is fairly clean:

Once you boot Samurai to the login screen you enter the username ’samurai’ and the password ’samurai’ to log in. This information is a little obscure. It appears on the Samurai SourceForge.net project page, and in the Readme.txt that is only available once you’re logged in to the distro:

Once logged in it becomes obvious that Samurai is based on Ubuntu, which is a little unusual for a live CD distribution:

Applications

Samurai comes with a host of useful applications. These include many of the regular Linux tools but also include:

• Burp Suite, a web application attacking tool
• DirBuster, an application file and directory enumeration and brute forcing tool from OWASP
• Fierce Domain Scanner a target ennumeration utility
• Gooscan an automated Google querying tool that is useful for finding CGI vulnerabilities without scanning the target directly, but rather querying Google’s caches
• Grendel-Scan, just released, an open source web application vulnerability testing tool
• HTTP_Print a web server fingerprinting tool
• Maltego CE, an open source intelligence and forensics application that does data mining to find information from the internet and link it together (great for background research on a target).
• Nikto, an open source web server scanner
• Paros, one of my favorite, Java based, cross platform, web application auditing and proxy tools
• Rat Proxy, a semi-automated, passive web application security audit tool.
• Spike Proxy, an extensible web application analyzer and vulnerability scanner.
• SQLBrute, a SQL injection and brute forcing tool.
• w3af (and the GUI), a web application attack and audit framework.
• Wapiti, a web application security auditor and vulnerability scanner
• WebScarab, an HTTP application auditing tool from OWASP
• WebShag, a web server auditing tool
• ZenMap, a NMAP graphical front end

Additionally Samurai includes several utilities that aren’t available from the GUI menu. These include:

• dnswalk, a DNS query and zone transfer tool
• httping, a ping like utility for HTTP requests
• httrack, a website copying utility.
• john the ripper, a password cracking program
• netcat, a TCIP/IP swiss army knife
• nmap, a port scanner and OS detection tool
• siege, an HTTP stress tester and benchmarking tool.
• snarf, a lightweight URL fetching utility

and many others. Of course, all of these tools could easily be installed on your own Linux based machine, but having a live CD with the tools installed and pre configured is quite nice. Samurai also comes with Wine installed, which is handy if you want to run some windows based tools off of the distribution.

Source: http://www.madirish.net/?article=218

w3af – Web Application Attack and Audit Framework

w3af, is a Web Application Attack and Audit Framework. The w3af core and it’s plugins are fully written in python. The project has more than 130 plugins, which check for SQL injection, cross site scripting (xss), local and remote file inclusion and much.

Download: http://sourceforge.net/projects/w3af/files/
FAQ: http://w3af.sourceforge.net/faq.php
User Guide: http://w3af.svn.sourceforge.net/viewvc/w3af/trunk/readme/EN/w3afUsersGuide.pdf
Video: http://www.youtube.com/watch?v=YABMASGv4A8 & http://www.youtube.com/watch?v=3UwQO3-Unt8

Samurai – Web Testing Framework

The Samurai Web Testing Framework is a live linux environment that has been pre-configured to function as a web pen-testing environment. The CD contains the best of the open source and free tools that focus on testing and attacking websites. In developing this environment, we have based our tool selection on the tools we use in our security practice. We have included the tools used in all four steps of a web pen-test.

Starting with reconnaissance, we have included tools such as the Fierce domain scanner and Maltego. For mapping, we have included tools such WebScarab and ratproxy. We then chose tools for discovery. These would include w3af and burp. For exploitation, the final stage, we included BeEF, AJAXShell and much more. This CD also includes a pre-configured wiki, set up to be the central information store during your pen-test.

Website: http://samurai.inguardians.com/
Video: http://www.vimeo.com/1790680
Live CD: http://sourceforge.net/projects/samurai/files/

F-Secure gets hacked (likewise)

The Romanian hacker that made the news this week by blowing the whistle on an SQL injection affecting two of the best known security software developers, Kaspersky and BitDefender, is not resting on his laurels and is now putting the Finish experts from F-Secure to the test. According to Unu, the alias used by the hacker in question, the web page of F-secure is vulnerable to SQL injection and XSS (cross site scripting); the good thing is that no confidential or sensitive data has been leaked. The only info that Unu managed to access is related to past virus activity and some statistics.

“During the last few days a Romanian group has been doing SQL injection attacks on several security vendor’s websites and early this morning they hit us,” replied F-Secure. “One of our servers used in gathering malware statistics had a page that didn’t properly sanitize input and was therefore vulnerable to attack. Fortunately we utilize defense-in-depth strategies so the attack was only partly successful. Although the attackers were able to read information from the database they couldn’t write or manipulate it. And they couldn’t access any other data on that server because the SQL user only had access to its own database, which only contains public information that is shown on our statistics pages. So while the attack is something we must learn from and points at things we need to improve, it’s not the end of the world.”

It may not be “the end of the world” but it is properly embarrassing when a company that specializes in security solutions is vulnerable to some sort of exploit or attack.

While Unu’s success may have been a limited, some other hacker has been successful in compromising the official web page of Germany’s Interior Minister, Wolfgang Schäuble. The attacker exploited a security vulnerability in the Typo3 content management system and placed the “Visit: Vorratsdatenspeicherung” message on the site. The attack seems to have been spurred by the minister’s support for biometric passports and logging all email, internet, landline and mobile phone communications.

Source:

http://www.findmysoft.com/news/SQL-Injection-Attack-on-F-Secure-Site-of-Germany-Ministry-of-Interior-Successfully-Hacked/

http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1347639,00.html

http://www.hackersblog.org/2009/02/11/f-securecom-sql-injection-cross-site-scripting/

TOP 25 Most Dangerous Programming Errors

These programming errors are categorised into 3 categories.

* Insecure Interaction Between Components (9 errors)
* Risky Resource Management (9 errors)
* Porous Defenses (7 errors)

CATEGORY: Insecure Interaction Between Components
CWE-20: Improper Input Validation
CWE-116: Improper Encoding or Escaping of Output
CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
CWE-79: Failure to Preserve Web Page Structure (aka ‘Cross-site Scripting’)
CWE-78: Failure to Preserve OS Command Structure (aka ‘OS Command Injection’)
CWE-319: Cleartext Transmission of Sensitive Information
CWE-352: Cross-Site Request Forgery (CSRF)
CWE-362: Race Condition
CWE-209: Error Message Information Leak

CATEGORY: Risky Resource Management
CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
CWE-642: External Control of Critical State Data
CWE-73: External Control of File Name or Path
CWE-426: Untrusted Search Path
CWE-94: Failure to Control Generation of Code (aka ‘Code Injection’)
CWE-494: Download of Code Without Integrity Check
CWE-404: Improper Resource Shutdown or Release
CWE-665: Improper Initialization
CWE-682: Incorrect Calculation

CATEGORY: Porous Defenses
CWE-285: Improper Access Control (Authorization)
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-259: Hard-Coded Password
CWE-732: Insecure Permission Assignment for Critical Resource
CWE-330: Use of Insufficiently Random Values
CWE-250: Execution with Unnecessary Privileges
CWE-602: Client-Side Enforcement of Server-Side Security

Source: http://www.sans.org/top25-programming-errors/

Imperva web application security videos

http://www.imperva.com/resources/videos.asp

Website maintenance

1. Take your website down for a certain period
It is recommended to take the website down as you do not want to be distributing malware or virus from your website to your visitors. The website should be offline while you are recovering the site.

2. Change all the passwords
Although this may seem like a simple step, many people, including myself, often fail to change all the passwords immediately after an attack has been discovered. You need to change all the passwords associated with the website; which include ftp passwords, ssh passwords, account passwords, database passwords, admin passwords and so on.

3. Take a copy of the affected website for further analysis
You may want to do a further analysis on the attack and might need to refer to the exact injection source code in the future. Take a copy of the affected website in a compressed format, eg: zip or gzip and store it in an quarantine area for later reference. Note that it is not advisable to keep the affected files on the server.

4. Replace the entire site with a clean backup copy
Do not rely on your hosting provider for a backup copy of your site. Many hosting providers say they do an automatic backup every night, however, it is more reliable if you have other backup solutions for your website.

5. Test the website and reopen
This is to make sure that the website is reverted to its clean, original version. Once you are happy with the result, you can reopen the website to the public.

6. Analyse how the attack was originated
In order to ensure that the same attack does not happen again, you will need to do a full analysis of the attack and how it was originated. Was it because of a security hole in your application? Was it caused by a weak file permission? Or is your server affected with some virus that injects these code into your website at regular interval? You will need to understand how it happens in order to prevent it in the future. And when necessary, obtain an expert advice.

7. Perform appropriate security measures based on the analysis
Although you may have recovered your website, it does not mean your website will not be attacked again. If the same security hole still exists, it is probably very likely that the website will be attacked again in the near future. Therefore, it is recommended that you perform necessary security measures, be it hardening your web server, upgrading an application, or introducing new security restrictions.

My experience and advice

I have encountered and recovered quite a few websites that had been attacked by malicious iframe exploit in the recent years. And the common causes seem to be as follows:

* The website is hosted on a cheap web hosting service
* The website is using an old version of an open source application (eg: WordPress 1.0) which has known security issues
* File permissions on the server are not set accordingly (eg: every file and folder on the server is set to 777 – read-write-execute)
* Weakness in an application code. For example, there is not sufficient input validation.
* FTP rather than SFTP is used
* There is no IP restriction for SSH and FTP accounts

There are a few simple things that can be done to reduce the risk of your website being attacked.

* Change your passwords periodically (say, at least once a month)
* Keep your applications up-to-date. Always upgrade immediately when a new version is available.
* Clean up files and directories on the web server. Make sure there is no old file with .bak or .txt extensions lying around
* Ensure that appropriate file permissions are used for every file and directory on the web server
* Consult with a security expert to obtain the best advice

source: http://eisabainyo.net/weblog/2009/04/06/iframe-injection-attack/

El error se encuentra curiosamente en una protección añadida por los programadores de Microsoft al navegador

La última versión de Internet Explorer incorpora un fallo a través del cual se puede realizar un ataque serio contra un sitio web que se consideraría seguro. La vulnerabilidad podrían permitir la ejecución de ataques XSS, o cross-site scripting y, según afirman en Securityfocus, Microsoft tiene conocimiento de ello desde hace unos meses.

Curiosamente el fallo reside en una protección añadida por los desarrolladores de Microsoft a Internet Explorer 8 que está diseñada para impedir ataques XXS contra páginas web. Esta características funciona reescribiendo páginas vulnerables utilizando una técnica conocida como ‘output encoding’ que reemplaza los caracteres y valores dañinos por unos buenos.

No está claro cómo la protección puede causar vulnerabilidades en sitios web que de otra forma serían seguros. Hay quien especula que IE8 reescribiría las páginas de manera que los nuevos valores desencadenaran un ataque en un sitio limpio.

Los ataques XXS son una manera de manipular las URL para inyectar código o contenido malicioso en una página web segura.

fuente: itespresso.es

Web applications are nice. They’re useful, they’re cross-platform, users need no installation, no upgrades, no maintenance, not even the computing or storage power to which they are used. As weird as it may sound, I’ve even seen announcements for web applications supposed to run your games on distant high-end computers so that you can actually play on low-end computers. Go web application!

Of course, there are a few downsides to web applications. Firstly, they require a web connexion. Secondly, they are largely composed of plumbing. Finally, ensuring their security is a constant fight.

How many pipes do you need?

If you have ever developed a web application, you know what I mean by plumbing: just writing an online TODO list — the equivalent of maybe twenty minutes of work in Visual Basic, in Python, Java or Objective-C — requires mixing an insane amount of languages, to define your user interface (HTML, JavaScript, CSS), to define your storage (DDL, DML, DCL, plus possibly an ORM language), to get your server and your client to communicate (XML, more JavaScript, PHP or one of its competitors, as well as some HTTP and a little MIME configuration), to launch your application (whichever configuration languages are used by your server). Of course, if your application is a bit more complex and requires something like compatibility with smartphones, or like distant storage, or distributed computing, or backups, or modularity (in the world of the web, it’s called “web services”)… well, you will probably require a few additional languages.

All of this is just plumbing. Only once you have written it can you concentrate on the core of the application. And once the application is written, the pain is just starting, because chances are that your application can be attacked by hijacking the link between your user interface and the core (cross-site scripting) or between the core and the storage (SQL injection) or by keeping the user interface and replacing the application core (man-in-the-middle attacks) or by replacing the user interface by a malicious client or by taking the place of a currently connected user to steal some of its credentials (rebinding) or by taking advantage of low-level bugs (buffer over/underflows), etc.

None of this is a show-stopper, of course — just take a look at the web and you will see thousands of web applications. Just like the complexity of Software Development Kits in the early days of Windows, MacOS or X didn’t stop adventurous hackers from developing desktop applications. But of course, if twenty-five years of desktop application development have taught us one thing, it is that the life of developers can be made easier. Nowadays, a few generations of SDKs later, Windows developers have .Net, C# and Visual Studio, Macintosh developers have Cocoa, Objective-C and XCode, while X-based developers have the libraries of Gnome/KDE, Python and a variety of programming environments. The growing popularity (and libraries) of Haskell, F#, OCaml, Scala and other functional programming languages could mean that one of the next generations of SDKs will increase safety and security.

The web hasn’t quite reached that stage yet. Even the state-of-the-art in web frameworks only provides features slightly more advanced than early Windows/Mac/X SDKs: low-level bindings for low-level mechanisms, designed to ensure low-level properties. Or, rephrased differently, in the current state of web development, GMail, Google Maps or Facebook are still considered complicated applications, although they are conceptually quite simple and should therefore be equally simple to implement.

We can do better. How? By removing the need for plumbing. By providing automated mechanisms for ensuring high-level security properties. By providing language support for common patterns.

Enter OPA

Let me introduce OPA. OPA, or One Pot Application, is a complete development platform for web applications and web services. Development in OPA requires no plumbing. Applications developed with OPA are automatically checked for safety and security before they are executed. Applications developed with OPA are automatically (and provably) immune to cross-site scripting, to SQL injections and to most existing forms of attacks. And OPA provides language support for storage, communication between client and server (Ajax and Comet), concurrency, distribution, mobility, etc.

With OPA, we intend to skip several generations of SDKs and provide right now a high-level and modern programming platform. OPA has been 6 years in the making: 4 years of sketches, mockups and prototypes as part of academic research projects and 2 years of actual implementation at MLstate. A few days ago, OPA has officially entered demonstrable status. Not quite ready for prime time, but definitely usable for development. Do you want to write an online note-taking application? That’s about 20 lines of code, from scratch. A minimal chat? About 30 lines. A multi-channel, distributed chat? About 80 lines. A minesweeper? About 100. We’re using it to develop utilities, content management systems, tools for administrations and games.

Pre-alpha builds of OPA have been distributed to selected partners. A public version will be made available within a few weeks, as well as commercial applications developed with OPA. In the meantime, we are busy improving the syntax, completing the standard library, making error messages intelligible, fixing the bugs and extending the range of safety and security checks.

Interested? Well, few details are public at this time. However, you can take a look at a video recorded during ICFP presenting OPA and MLstate.

Stay tuned.

A first release candidate for the OWASP Top 10 2010 was released a while ago. In my view the best enhancement is the new design of document.

As I worked on some short executive summaries for my company, I always struggled how to get a lot of information in the shortest form possible. The new OWASP Top10 PDF design is kind of perfect for this matter.

Document (Download as PDF):

#####################################
Google Chrome Frame null domain XSS
URL afectada: http://www.google.com/chromeframe
Changelog del vendedor: http://googlechromereleases.blogspot.com/2009/11/google-chrome-frame-update-bug-fixes.html
Reportado por: http://lostmon.blogspot.com/2009/11/google-chrome-frame-null-domain-xss.html
Notificación al vendedor: SÍ Exploit disponible: SÍ
######################################

######################
Descripción del vendedor
######################

Google Chrome Frame es un plug-in gratuito para Internet Explorer. Algunas aplicaciones web avanzadas, como Google Wave, contiene el uso de Google Chrome Frame para ofrecerle características adicionales y un mejor rendimiento.

Google Chrome Frame es una etapa inicial de código abierto, un plug-in que hace a la perfección Google Chrome mejorando las tecnologías web y el motor de JavaScript de Internet Explorer.

################
Versiones afectadas
################

4.0.223.9 (Official Build 29618)
WebKit: 532.3
V8: 1.3.16
User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/532.3 (KHTML, like Gecko) Chrome/4.0.223.9 Safari/532.3

Versiones no afectadas:

4.0.245.1 (Official Build 31970)
WebKit: 532.5
V8: 1.3.18.6
User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.245.1 Safari/532.5

Para más información visiten:

http://googlechromereleases.blogspot.com/2009/11/google-chrome-frame-update-bug-fixes.html

#####################
Cross Site Scripting
#####################

Creamos un documento HTML para probar y metemos =>

<iframe src=”javascript:alert(1)></iframe>

=> se abre el iframe y ejecuta el alert (esto es lo correcto)

<iframe src=”cf:javascript:alert(1)></iframe>

=> esto no funciona, no muestra el alert (sigue siendo correcto)

Y aquí está el error:

<iframe src=”cf:view-source:javascript:alert(1)></iframe>

Este code ejecuta y muestra el alert que funciona en local y a su vez en remoto o también a través de la barra de dirección.

Esto pasa las políticas de origen de datos !!

Para probar el navegador Google Chrome ponemos en la barra de dirección =>

view-source:javascript:alert(1)

Esto ejecuta el alert, aun así Google hace poco decidió realizar unos cambios en él como poner la página en blanco, este tema es sólo explotable a través de la barra de direcciones, no en un iframe o frame o documento html, así que por ese motivo creo que este problema no es explotable remotamente.

###########
Crashes
###########

cf:view-source:about@: => se rompe
cf:about@: => rompe el tab

##########
Solución
############

Google automáticamente ha sacado una nueva versión de Chrome Frame 4.0.245.1 (Official Build 31970) y esta versión no está afectada por esta vulnerabilidad.

#################€nd#############

Thnx to estrella To be mi ligth
Thnx To icar0 & sha0 from Badchecksum
Thnx To Google security Team

atentamente:
Security Research & Analisys.
Lostmon (lostmon@gmail.com)
—————–

thz Lost

Se ha encontrado una vulnerabilidad en IBM WebSphere Application Server (versiones 6.1.x y 7.x) que podría ser explotada por un atacante remoto para conducir ataques de cross-site scripting.

IBM WebSphere Application Server (WAS) es el servidor de aplicaciones de software de la familia WebSphere de IBM. WAS puede funcionar con diferentes servidores web y sistemas operativos incluyendo Apache HTTP Server, Netscape Enterprise Server, Microsoft Internet Information Services (IIS), IBM HTTP Server en sistemas operativos AIX, Linux, Microsoft, Windows y Solaris.

La vulnerabilidad está causada por un error de validación de entradas cuando procesa los datos introducidos por el usuario en la Consola de Administración. Esto podría ser explotado por un atacante remoto para ejecutar código arbitrario HTML y JavaScrip en el contexto de la sesión del navegador de un usuario que visita un sitio afectado.

• Para WebSphere Application Server 6.1 se recomienda instalar el último Fix Pack (6.1.0.29 o posterior) o el APAR PK92057.
• Para WebSphere Application Server 7.0 se recomienda instalar el último Fix Pack (7.0.0.7 o posterior) o el APAR PK92057.

REFERENCIA

IBM WebSphere Application Server Administration Console cross-site scripting

http://xforce.iss.net/xforce/xfdb/54229

fuente: hispasec.com

]]> http://abtisci.wordpress.com/2009/11/19/precauciones-basicas-para-evitar-ataques-web-en-asp/ Thu, 19 Nov 2009 19:28:48 +0000 therm000 http://abtisci.wordpress.com/2009/11/19/precauciones-basicas-para-evitar-ataques-web-en-asp/

Escribí un pequeño repaso de como evitar ataques web SQL y JavaScript en ASP. Este lenguaje de programación ya tiene varios años y cuando salió no eran tan conocidos estos ataques de inyección de código, entonces en general por defecto las aplicaciones web ASP son vulnerables. En ASP .Net ya hay más funciones y conciencia de estos ataques, tal vez escriba otro artículo sobre ASP .Net si alguien lo pide.

Artículo

For Thursday November 19th, and Friday November 20th, we depart from our regular format for those with an advanced understanding of information security technologies.

These two special editions feature technical conversations with newsmakers on new counter measures to fight web drive-by downloads. Part one (this episode) features Pedro Bustamante, Senior Security Researcher with PandaSecurity. Part two will post tomorrow, with an EXCLUSIVE interview with the creators of a new hardware sandbox approach to this vexing security issue.

We will return to our regular format of the latest news on data security, privacy, and the law with Episode 82.  Episode 82 is scheduled to post Sunday night /Monday morning, November 23rd, 2009 at ~12.01am Greenwich Mean Time. That is our regularly scheduled show posting time.

On Episode 80:  InfoSec Conversation with Pedro Bustamante on countering web drive-by downloads.

–> Stream This Special Episode with our Built-In Flash Player:

–> Scroll down to see links and show notes for this week’s show

–> Stream, subscribe or download Episode 80 – Listen or subscribe to the feed to automatically get the latest episode sent to you to your Google, Yahoo, iTunes, or other popular sites.

–>Tune into the show directly on iTunes, you can also subscribe to the program on iTunes.

–> A simple way to listen to the show from with stricter firewalls: Listen from Odeo. This site works better if you are behind a more restrictive enterprise firewall.

Please visit our sponsors, and be sure to let them know you heard about them on The Data Security Podcast:

• Vipre Anti-Virus, the complete Antimalware solution by Sunbelt Software. If you TRY the enterprise version, you get the home version forFREE! Go to: http://www.testdrivevipre.com .

• GamaSec Web App Scans: Spots cyber-hazards on your web site, and has advanced zero-day protection. GET YOUR FREE BASIC WEB APP SCAN, plus a special offer just for listeners to The Data Security Podcast. Go here to sign up, and add the offer code: Podcast.

• SonicWall;  Get the super fast UTM firewall that’s rated Five Stars (the Best rating) by Secure Computing Magazine.  Data Clone Labs is the premier SonicWall Medallion Partner for all your security needs.

• DeviceLock; Software that controls, manages and helps encrypt USB drives and other removable media. Get a free trial on their site, and be sure to let them know you heard about them on The Data Security Podcast.

Show Notes for Episode 80 of the Data Security Podcast

Ira has an extended, technical conversation with Pedro Bustamante, Senior Security Researcher with PandaSecurity. Ira and Pedro will discuss web drive-by downloads. Here is the link that Pedro mentions in the segment.