The document describes a vulnerability where the target server supports weak TLS/SSL ciphers and protocols, including SSLv2. This could allow attackers to decrypt encrypted communications and compromise sensitive data through man-in-the-middle attacks. Recommendations include disabling weak ciphers and protocols like SSLv2 to strengthen the security of encrypted connections.
“Are you one of them, who thinks that Cross-Site Scripting is just for some errors or pop-ups on the screen?” Yes?? Then today in this article, you’ll see how an XSS suffering web-page is not only responsible for the defacement of the web-application but also, it could disrupt a visitor’s privacy by sharing the login credentials or his authenticated cookies to an attacker without his/her concern.
Web 2.0 Application Kung-Fu - Securing Ajax & Web ServicesShreeraj Shah
The document summarizes Shreeraj Shah's presentation on securing Ajax and web services. It discusses trends in web 2.0 technologies like Ajax and web services being adopted by many companies, and outlines various attacks and defenses related to securing these technologies, including cross-site scripting, injection flaws, and insecure direct object references in web services. It also proposes methodologies for assessing web services security, including footprinting, profiling, scanning for vulnerabilities, and implementing defenses like firewalls and secure coding practices.
This document discusses DOM based cross-site scripting (XSS) and methods for detecting it. It begins by explaining what DOM and XSS are, and defines DOM based XSS as exploiting client-side script execution by modifying the DOM environment. Next, it provides examples of how DOM based XSS can work by manipulating DOM objects like document.location. The document concludes by outlining approaches for detecting DOM based XSS including general analysis, using the headless browser PhantomJS to programmatically interact with web pages, and leveraging a modified version of PhantomJS called Tainted PhantomJS that is designed specifically for DOM based XSS detection.
Silverlight 2 applications are security transparent and cannot contain unverifiable code, call native code directly, or access resources across domains by default. The enableHtmlAccess and ExternalCallersFromCrossDomain parameters can be used to selectively allow access between Silverlight and JavaScript and between cross-domain Silverlight applications and hosts. Silverlight supports same-domain HTTP requests by default and cross-domain requests if allowed by a clientaccesspolicy.xml file on the target domain.
This document discusses web application security from the perspectives of web developers and attackers. It covers common issues web developers face, such as tight deadlines and lack of security standards. It also describes how attackers exploit vulnerabilities like injection attacks and XSS. Recent attacks are presented as examples, such as compromising a power grid operator's website through SQL injection. The document aims to raise awareness of web security challenges.
OAuth 2.0
Oauth2.0 is an “authorization” framework for web applications. It permits selective access to a user’s resource without disclosing the password to the website which asks for the resource.
Agenda for the session:
What is Oauth 2.0
Oauth 2.0 Terminologies
Oauth workflow
Exploiting Oauth for fun and profit
Reference
Hacking Web 2.0 - Defending Ajax and Web Services [HITB 2007 Dubai]Shreeraj Shah
This document summarizes a presentation about assessing the security of Web 2.0 technologies like Ajax and web services. It discusses the Web 2.0 industry trends, technologies like Ajax, potential security impacts, and methodologies for fingerprinting, enumerating, crawling, and scanning Ajax applications and web services to identify vulnerabilities. It also provides an overview of attacking Ajax and defending applications.
Cross-site scripting (XSS) is one of the most common web application attacks, where malicious scripts are injected into otherwise benign websites. There are three main types of XSS attacks - stored, reflected, and DOM-based. To prevent XSS, developers should sanitize user input by removing hazardous characters, properly escape untrusted output before displaying it, and enforce a specific character encoding.
“Are you one of them, who thinks that Cross-Site Scripting is just for some errors or pop-ups on the screen?” Yes?? Then today in this article, you’ll see how an XSS suffering web-page is not only responsible for the defacement of the web-application but also, it could disrupt a visitor’s privacy by sharing the login credentials or his authenticated cookies to an attacker without his/her concern.
Web 2.0 Application Kung-Fu - Securing Ajax & Web ServicesShreeraj Shah
The document summarizes Shreeraj Shah's presentation on securing Ajax and web services. It discusses trends in web 2.0 technologies like Ajax and web services being adopted by many companies, and outlines various attacks and defenses related to securing these technologies, including cross-site scripting, injection flaws, and insecure direct object references in web services. It also proposes methodologies for assessing web services security, including footprinting, profiling, scanning for vulnerabilities, and implementing defenses like firewalls and secure coding practices.
This document discusses DOM based cross-site scripting (XSS) and methods for detecting it. It begins by explaining what DOM and XSS are, and defines DOM based XSS as exploiting client-side script execution by modifying the DOM environment. Next, it provides examples of how DOM based XSS can work by manipulating DOM objects like document.location. The document concludes by outlining approaches for detecting DOM based XSS including general analysis, using the headless browser PhantomJS to programmatically interact with web pages, and leveraging a modified version of PhantomJS called Tainted PhantomJS that is designed specifically for DOM based XSS detection.
Silverlight 2 applications are security transparent and cannot contain unverifiable code, call native code directly, or access resources across domains by default. The enableHtmlAccess and ExternalCallersFromCrossDomain parameters can be used to selectively allow access between Silverlight and JavaScript and between cross-domain Silverlight applications and hosts. Silverlight supports same-domain HTTP requests by default and cross-domain requests if allowed by a clientaccesspolicy.xml file on the target domain.
This document discusses web application security from the perspectives of web developers and attackers. It covers common issues web developers face, such as tight deadlines and lack of security standards. It also describes how attackers exploit vulnerabilities like injection attacks and XSS. Recent attacks are presented as examples, such as compromising a power grid operator's website through SQL injection. The document aims to raise awareness of web security challenges.
OAuth 2.0
Oauth2.0 is an “authorization” framework for web applications. It permits selective access to a user’s resource without disclosing the password to the website which asks for the resource.
Agenda for the session:
What is Oauth 2.0
Oauth 2.0 Terminologies
Oauth workflow
Exploiting Oauth for fun and profit
Reference
Hacking Web 2.0 - Defending Ajax and Web Services [HITB 2007 Dubai]Shreeraj Shah
This document summarizes a presentation about assessing the security of Web 2.0 technologies like Ajax and web services. It discusses the Web 2.0 industry trends, technologies like Ajax, potential security impacts, and methodologies for fingerprinting, enumerating, crawling, and scanning Ajax applications and web services to identify vulnerabilities. It also provides an overview of attacking Ajax and defending applications.
Cross-site scripting (XSS) is one of the most common web application attacks, where malicious scripts are injected into otherwise benign websites. There are three main types of XSS attacks - stored, reflected, and DOM-based. To prevent XSS, developers should sanitize user input by removing hazardous characters, properly escape untrusted output before displaying it, and enforce a specific character encoding.
The document discusses several common web application vulnerabilities and how attackers exploit them as well as recommendations for programmers to prevent exploits. It covers vulnerabilities like cross-site scripting, SQL injection, improper error handling, HTTP response splitting, and insecure session management. For each issue, it provides examples of vulnerable code, how attackers can take advantage, and techniques programmers can use to secure the code like input validation, output encoding, parameterized queries, and secure session IDs. The goal is to help both attackers and programmers understand each other's perspectives on web application security issues.
Enterprise API adoption has gone beyond predictions. It has become the 'coolest' way of exposing business functionalities to the outside world. Both your public and private APIs, need to be protected, monitored and managed.
This session focuses on API Security. There are so many options out there to make someone easily confused. When to select one over the other is always a question - and you need to deal with it quite carefully to identify and isolate the tradeoffs. Security is not an afterthought. It has to be an integral part of any development project - so as for APIs. API security has evolved a lot in last five years. This talk covers best practices in building an API Security Ecosystem with OAuth 2.0, UMA, SCIM, XACML and LDAP.
In the past few years with the rise of technological innovations, there has been an increase in the number and sophistication of security breaches. Poor input validation has turned out to be the root cause of these embarrassing data breaches reported in the last few years.
Hackers versus Developers and Secure Web ProgrammingAkash Mahajan
This document discusses hackers and developers and their different perspectives. Hackers try to find weaknesses and gain access in unintended ways, while developers aim to create secure systems. It notes that hackers only need one opening to exploit a system, while developers must constantly work to maintain security. The good fight is about making secure apps and safeguarding data, and hackers play a necessary role in incentivizing developers. Web app security risks include injection attacks and compromising user data. Developers must validate all untrusted input and encode output to build integrity.
The document summarizes the OWASP 2013 top 10 list of web application security risks. It provides descriptions and examples for each of the top 10 risks: 1) Injection, 2) Broken Authentication and Session Management, 3) Cross-Site Scripting (XSS), 4) Insecure Direct Object References, 5) Cross-Site Request Forgery (CSRF), 6) Security Misconfiguration, 7) Sensitive Data Exposure, 8) Missing Function Level Access Control, 9) Using Components with Known Vulnerabilities, and 10) Unvalidated Redirects and Forwards. Protection strategies are also outlined for each risk.
The document summarizes the OWASP Top 10 risks for 2013 and provides details on each risk. It introduces the new title for the risks as the "Top 10 Most Critical Web Application Security Risks" and notes they are now based on a risk rating methodology. Injection, XSS, and broken authentication remain the top risks. The document provides examples and recommendations for avoiding each risk.
This document provides API security best practices and guidelines. It discusses defining APIs and who may access them, such as employees, partners, customers or the general public. Authentication can be direct, using credentials, or brokered, using a third party. Best practices include using TLS, strong credentials, short-lived tokens, and throttling access. The guidelines aim to prevent attacks like CSRF, authorization code interception, and brute force attacks through measures like state parameters, PKCE, and long random tokens.
Companion slides for Stormpath CTO and Co-Founder Les REST API Security Webinar. This presentation covers all the RESTful best practices learned building the Stormpath APIs. This webinar is full of best practices learned building the Stormpath API and supporting authentication for thousands of projects. Topics Include:
- HTTP Authentication
- Choosing a Security Protocol
- Generating & Managing API Keys
- Authorization & Scopes
- Token Authentication with JSON Web Tokens (JWTs)
- Much more...
Stormpath is a User Management API that reduces development time with instant-on, scalable user infrastructure. Stormpath's intuitive API and expert support make it easy for developers to authenticate, manage and secure users and roles in any application.
This document discusses best practices for building an API security ecosystem, including using a gateway pattern to decouple clients from APIs, various methods for direct authentication of internal users like HTTP basic authentication and OAuth, auditing and monitoring APIs, and externalizing authorization using standards like XACML. It also covers cross-domain access, distributed authorization with resource servers, and user-managed access models.
Blackhat11 shreeraj reverse_engineering_browserShreeraj Shah
Hacking browser components by Reverse Engineering is emerging as the best way for discovering
potential vulnerabilities across web applications in an era of Rich Internet Applications (RIA). The RIA
space is flooded with technologies like HTML 5, Flex/Flash, Silverlight, extended DOM and numerous
third party libraries. Browsers are the target of hackers, worms and malware with specific scope, almost
on a daily basis. We have seen exploitation of these technologies on popular sites like Facebook, Twitter,
Yahoo, Google, to name a few. The traditional boundaries of web applications are disappearing.
Browsers today host a substantial part of web applications including data access, business logic,
encryption, etc. along with presentation layer. This shift is making browser components a potential
target for hackers. The danger of poorly written browser components being
http://www.justin.tv/hackertv/49975/Tech_Talk_1_Leah_Culver_on_OAuth
Tech talk about OAuth, and open standard for API authentication. Originally broadcast on Justin.tv.
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its own behalf.
This talk is about how to secure your front-end + backend applications using a RESTful approach. As opposed to traditional and monolithic server-side applications (where the HTTP session is used), when your front-end application is running on a browser and not securely from the server, there are few things you need to consider.
In this session Alvaro will explore standards like OAuth or JWT to achieve a stateless, token-based authentication and authorization using Spring Security in Grails.
The document discusses OAuth 2.0 and how it addresses issues with traditional approaches to authorizing third party access to user accounts and resources. It provides an overview of OAuth 2.0 concepts like authorization grants, access tokens, refresh tokens, and the roles of the client, resource owner, authorization server and resource server. It then describes the authorization code grant flow and client credentials flow in more detail through examples. The goal is to explain how OAuth 2.0 works and how it can be used to securely authorize access to resources while avoiding the risks of directly sharing user credentials.
Cyber attacks are a real and growing threat to businesses and an increasing number of attacks take place at application layer. The best defence against is to develop applications where security is incorporated as part of the software development lifecycle.
The OWASP Top 10 Proactive Controls project is designed to integrate security in the software development lifecycle. In this special presentation for PHPNW, based on v2.0 released this year, you will learn how to incorporate security into your software projects.
Recommended to all developers who want to learn the security techniques that can help them build more secure applications.
Securing RESTful APIs using OAuth 2 and OpenID ConnectJonathan LeBlanc
Constructing a successful and simple API is the lifeblood of your developer community, and REST is a simple standard through which this can be accomplished. As we construct our API and need to secure the system to authenticate and track applications making requests, the open standard of OAuth 2 provides us with a secure and open source method of doing just this. In this talk, we will explore REST and OAuth 2 as standards for building out a secure API infrastructure, exploring many of the architectural decisions that PayPal took in choosing variations in the REST standard and specific implementations of OAuth 2.
logout.php Session Data after Logout Username Email . $_.docxsmile790243
logout.php
Session Data after Logout
Username Email " . $_SESSION['appusername'] . "
" .
"" . $_SESSION['appemail'] . "
";
?>
ZAP Scanning Report for loginAuthReport.odt
ZAP Scanning Report
Summary of Alerts
Risk Level
Number of Alerts
High
2
Medium
1
Low
5
Informational
3
Alert Detail
High (Warning)
Cross Site Scripting (Reflected)
Description
Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.
There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.
URL
http://localhost/week4/authcheck.php
Parameter
username
Attack
</td><script>alert(1);</script><td>
Solution
Phase ...
The document discusses several common web application vulnerabilities and how attackers exploit them as well as recommendations for programmers to prevent exploits. It covers vulnerabilities like cross-site scripting, SQL injection, improper error handling, HTTP response splitting, and insecure session management. For each issue, it provides examples of vulnerable code, how attackers can take advantage, and techniques programmers can use to secure the code like input validation, output encoding, parameterized queries, and secure session IDs. The goal is to help both attackers and programmers understand each other's perspectives on web application security issues.
Enterprise API adoption has gone beyond predictions. It has become the 'coolest' way of exposing business functionalities to the outside world. Both your public and private APIs, need to be protected, monitored and managed.
This session focuses on API Security. There are so many options out there to make someone easily confused. When to select one over the other is always a question - and you need to deal with it quite carefully to identify and isolate the tradeoffs. Security is not an afterthought. It has to be an integral part of any development project - so as for APIs. API security has evolved a lot in last five years. This talk covers best practices in building an API Security Ecosystem with OAuth 2.0, UMA, SCIM, XACML and LDAP.
In the past few years with the rise of technological innovations, there has been an increase in the number and sophistication of security breaches. Poor input validation has turned out to be the root cause of these embarrassing data breaches reported in the last few years.
Hackers versus Developers and Secure Web ProgrammingAkash Mahajan
This document discusses hackers and developers and their different perspectives. Hackers try to find weaknesses and gain access in unintended ways, while developers aim to create secure systems. It notes that hackers only need one opening to exploit a system, while developers must constantly work to maintain security. The good fight is about making secure apps and safeguarding data, and hackers play a necessary role in incentivizing developers. Web app security risks include injection attacks and compromising user data. Developers must validate all untrusted input and encode output to build integrity.
The document summarizes the OWASP 2013 top 10 list of web application security risks. It provides descriptions and examples for each of the top 10 risks: 1) Injection, 2) Broken Authentication and Session Management, 3) Cross-Site Scripting (XSS), 4) Insecure Direct Object References, 5) Cross-Site Request Forgery (CSRF), 6) Security Misconfiguration, 7) Sensitive Data Exposure, 8) Missing Function Level Access Control, 9) Using Components with Known Vulnerabilities, and 10) Unvalidated Redirects and Forwards. Protection strategies are also outlined for each risk.
The document summarizes the OWASP Top 10 risks for 2013 and provides details on each risk. It introduces the new title for the risks as the "Top 10 Most Critical Web Application Security Risks" and notes they are now based on a risk rating methodology. Injection, XSS, and broken authentication remain the top risks. The document provides examples and recommendations for avoiding each risk.
This document provides API security best practices and guidelines. It discusses defining APIs and who may access them, such as employees, partners, customers or the general public. Authentication can be direct, using credentials, or brokered, using a third party. Best practices include using TLS, strong credentials, short-lived tokens, and throttling access. The guidelines aim to prevent attacks like CSRF, authorization code interception, and brute force attacks through measures like state parameters, PKCE, and long random tokens.
Companion slides for Stormpath CTO and Co-Founder Les REST API Security Webinar. This presentation covers all the RESTful best practices learned building the Stormpath APIs. This webinar is full of best practices learned building the Stormpath API and supporting authentication for thousands of projects. Topics Include:
- HTTP Authentication
- Choosing a Security Protocol
- Generating & Managing API Keys
- Authorization & Scopes
- Token Authentication with JSON Web Tokens (JWTs)
- Much more...
Stormpath is a User Management API that reduces development time with instant-on, scalable user infrastructure. Stormpath's intuitive API and expert support make it easy for developers to authenticate, manage and secure users and roles in any application.
This document discusses best practices for building an API security ecosystem, including using a gateway pattern to decouple clients from APIs, various methods for direct authentication of internal users like HTTP basic authentication and OAuth, auditing and monitoring APIs, and externalizing authorization using standards like XACML. It also covers cross-domain access, distributed authorization with resource servers, and user-managed access models.
Blackhat11 shreeraj reverse_engineering_browserShreeraj Shah
Hacking browser components by Reverse Engineering is emerging as the best way for discovering
potential vulnerabilities across web applications in an era of Rich Internet Applications (RIA). The RIA
space is flooded with technologies like HTML 5, Flex/Flash, Silverlight, extended DOM and numerous
third party libraries. Browsers are the target of hackers, worms and malware with specific scope, almost
on a daily basis. We have seen exploitation of these technologies on popular sites like Facebook, Twitter,
Yahoo, Google, to name a few. The traditional boundaries of web applications are disappearing.
Browsers today host a substantial part of web applications including data access, business logic,
encryption, etc. along with presentation layer. This shift is making browser components a potential
target for hackers. The danger of poorly written browser components being
http://www.justin.tv/hackertv/49975/Tech_Talk_1_Leah_Culver_on_OAuth
Tech talk about OAuth, and open standard for API authentication. Originally broadcast on Justin.tv.
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its own behalf.
This talk is about how to secure your front-end + backend applications using a RESTful approach. As opposed to traditional and monolithic server-side applications (where the HTTP session is used), when your front-end application is running on a browser and not securely from the server, there are few things you need to consider.
In this session Alvaro will explore standards like OAuth or JWT to achieve a stateless, token-based authentication and authorization using Spring Security in Grails.
The document discusses OAuth 2.0 and how it addresses issues with traditional approaches to authorizing third party access to user accounts and resources. It provides an overview of OAuth 2.0 concepts like authorization grants, access tokens, refresh tokens, and the roles of the client, resource owner, authorization server and resource server. It then describes the authorization code grant flow and client credentials flow in more detail through examples. The goal is to explain how OAuth 2.0 works and how it can be used to securely authorize access to resources while avoiding the risks of directly sharing user credentials.
Cyber attacks are a real and growing threat to businesses and an increasing number of attacks take place at application layer. The best defence against is to develop applications where security is incorporated as part of the software development lifecycle.
The OWASP Top 10 Proactive Controls project is designed to integrate security in the software development lifecycle. In this special presentation for PHPNW, based on v2.0 released this year, you will learn how to incorporate security into your software projects.
Recommended to all developers who want to learn the security techniques that can help them build more secure applications.
Securing RESTful APIs using OAuth 2 and OpenID ConnectJonathan LeBlanc
Constructing a successful and simple API is the lifeblood of your developer community, and REST is a simple standard through which this can be accomplished. As we construct our API and need to secure the system to authenticate and track applications making requests, the open standard of OAuth 2 provides us with a secure and open source method of doing just this. In this talk, we will explore REST and OAuth 2 as standards for building out a secure API infrastructure, exploring many of the architectural decisions that PayPal took in choosing variations in the REST standard and specific implementations of OAuth 2.
logout.php Session Data after Logout Username Email . $_.docxsmile790243
logout.php
Session Data after Logout
Username Email " . $_SESSION['appusername'] . "
" .
"" . $_SESSION['appemail'] . "
";
?>
ZAP Scanning Report for loginAuthReport.odt
ZAP Scanning Report
Summary of Alerts
Risk Level
Number of Alerts
High
2
Medium
1
Low
5
Informational
3
Alert Detail
High (Warning)
Cross Site Scripting (Reflected)
Description
Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.
There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.
URL
http://localhost/week4/authcheck.php
Parameter
username
Attack
</td><script>alert(1);</script><td>
Solution
Phase ...
Cross site scripting (XSS) is a type of computer security vulnerability typically found in web applications, but in proposing defensive measures for cross site scripting the websites validate the user input and determine if they are vulnerable to cross site scripting. The major considerations are input validation and output sanitization.
There are lots of defense techniques introduced nowadays and even though the coding methods used by developers are evolving to counter attack cross site scripting techniques, still the security threat persist in many web applications for the following reasons:
• The complexity of implementing the codes or methods.
• Non-existence of input data validation and output sanitization in all input fields of the application.
• Lack of knowledge in identifying hidden XSS issues etc.
This proposed project report will briefly discuss what cross site scripting is and highlight the security features and defense techniques that can help against this widely versatile attack.
This presentation is from Null/OWASP/G4H November Bangalore MeetUp 2014.
technology.inmobi.com/events/null-owasp-g4h-november-meetup
Talk Outline:-
A) Reflective-(Non-Persistent Cross-site Scripting)
- What is Reflective Cross-site scripting.
- Testing for Reflected Cross site scripting
How to Test
- Black Box testing
- Bypass XSS filters
- Gray Box testing
Tools
Defending Against Reflective Cross-site scripting.
Examples of Reflective Cross-Site Scripting Attacks.
B) Stored -(Persistent Cross-site Scripting)
What is Stored Cross-site scripting.
How to Test
- Black Box testing
- Gray Box testing
Tools
Defending Against Stored Cross-site scripting.
Examples of Stored Cross-Site Scripting Attacks.
This document discusses cross-site scripting (XSS) vulnerabilities. It explains that XSS allows malicious users to insert client-side scripts into web pages that are then executed by a user's browser when they visit the page. This can enable attackers to steal cookies and private information, perform actions as the user, and redirect users to malicious sites. The document outlines different types of XSS attacks, including non-persistent XSS that only affects the current user, persistent XSS where malicious code is saved to a database and affects all users, and DOM-based XSS that modifies the DOM environment. It provides examples of how XSS payloads can be inserted and recommendations for preventing XSS like sanitizing user input and output
Owasp Top 10 - Owasp Pune Chapter - January 2008abhijitapatil
The document discusses various cybersecurity topics including vulnerabilities, threats, attacks, and countermeasures. It provides an overview of the Open Web Application Security Project (OWASP) which focuses on improving application security. It also summarizes common web vulnerabilities like cross-site scripting (XSS), SQL injection, buffer overflows, and cross-site request forgery (CSRF). Recommendations are given to prevent these vulnerabilities.
Cross Site Scripting (XSS) is a vulnerability that allows malicious users to insert client-side code into web pages that is then executed by a user's browser. This code can steal cookies, access private information, perform actions on the user's behalf, and redirect them to malicious websites. XSS works by having the server display input containing malicious JavaScript from a request. There are different types of XSS attacks, including non-persistent, persistent, and DOM-based attacks. Prevention methods include validating, sanitizing, and escaping all user input on the server-side and client-side. Web vulnerability scanners like Burp Suite can help test for XSS and other vulnerabilities.
The document presents a hierarchical classification of web vulnerabilities organized into two main groups: general vulnerabilities that affect all web servers and service-specific vulnerabilities found in particular web server programs. General vulnerabilities are further divided into three sub-groups: feature abuse involving misuse of legitimate features, unvalidated input where user input is not checked before being processed, and improper design flaws. Validating user input and disabling vulnerable features can help eliminate certain vulnerability types like cross-site scripting resulting from unvalidated input or cross-site tracing from feature abuse. The hierarchy aims to help webmasters understand and address vulnerabilities by grouping similar issues.
The document summarizes the OWASP Top 10 vulnerabilities for 2013. It describes OWASP as an organization that publishes information about web application security vulnerabilities. It then lists and briefly describes the top 10 vulnerabilities, which include injection flaws, broken authentication, cross-site scripting, insecure direct object references, security misconfiguration, sensitive data exposure, missing access controls, cross-site request forgery, use of vulnerable components, and unvalidated redirects/forwards.
Cross Site Scripting (XSS) is a type of vulnerability that allows attackers to inject client-side scripts into web pages viewed by other users. There are three main types: persistent XSS saves the attack script on the server; reflected XSS executes a script based on user-supplied input; and DOM-based XSS occurs when active browser content processes untrusted user input. Attackers use XSS to steal session cookies or other private information that can be used to impersonate users.
XSS: From alert(1) to crypto mining malwareOmer Meshar
Cross-site scripting (XSS) allows malicious scripts to be injected into otherwise benign websites. There are three main types of XSS attacks: stored, reflected, and DOM-based. Attackers use XSS to conduct activities like session hijacking, phishing, installing malware, and crypto mining. Defenses against XSS include input validation, output encoding, security headers, code reviews, and web application firewalls. XSS remains a challenging problem even with preventative measures in place.
XSS (cross-site scripting) is a common web vulnerability that allows attackers to inject client-side scripts. The document discusses various types of XSS attacks and defenses against them. It covers:
1) Reflected/transient XSS occurs when untrusted data in URL parameters is immediately displayed without sanitization. Stored/persistent XSS occurs when untrusted data is stored and later displayed. DOM-based XSS manipulates the DOM.
2) Defenses include HTML/URL encoding untrusted data before displaying it, validating all inputs, and using context-specific encoding for HTML elements, attributes, JavaScript, and URLs.
3) The OWASP Java Encoder Project and Microsoft Anti
Cross-site scripting (XSS) and cross-site request forgery (CSRF) are web security vulnerabilities. XSS occurs when a malicious script is executed in a user's browser session from a web application. CSRF tricks a user's browser into making requests to a trusted site where the user is currently authenticated. The Samy worm exploited an XSS vulnerability on MySpace to propagate to over 1 million user profiles in under 24 hours. Developers can prevent XSS by validating and encoding all user input, and prevent CSRF by requiring secret tokens in POST requests.
Web application attacks can take many forms, including cross-site scripting (XSS), SQL injection, parameter tampering, command injection, session management issues, cookie poisoning, directory traversal, cross-site request forgery, and buffer overflows. XSS is a vulnerability that allows malicious JavaScript code to be injected and run in a user's browser, potentially accessing data. SQL injection involves inserting SQL commands into a database query to gain unauthorized access. Parameter tampering modifies URL parameters to change expected behavior.
The document discusses common security vulnerabilities in React applications such as cross-site scripting (XSS), injection attacks, CSRF attacks, malicious file uploads, insufficient authorization and authentication, distributed denial of service (DDoS) attacks, and XML external entity (XXE) attacks. It provides recommendations for how to prevent and fix each vulnerability, such as strict escaping to prevent XSS, validating all uploads, and using JSON web tokens for authorization. The document also mentions other vulnerabilities to consider like server-side rendering security and dangerous URI schemes.
This document discusses cross-site scripting (XSS) attacks against mobile applications. It defines XSS as a type of injection where malicious scripts are injected into trusted websites. The document describes three types of XSS attacks - reflected XSS, stored XSS, and DOM-based XSS. It provides examples of each type of attack and how attackers are able to execute scripts on a victim's machine by injecting code. The document concludes with recommendations for preventing XSS attacks, including validating all input data, encoding all output data, and setting the proper character encoding.
Introduction to Cross Site Scripting ( XSS )Irfad Imtiaz
Contents :
- Introduction
- Description as A Widely Used Hacking Technique
- How it is used in Hacking
- What can be done with XSS
#XSS, #Hacking, #Security, #CookieStealing, #InternetBug, #HTMLInjection
Sincerely,
Irfad Imtiaz
IRJET- A Survey on Various Cross-Site Scripting Attacks and Few Prevention Ap...IRJET Journal
This document discusses cross-site scripting (XSS) attacks and methods to prevent them. It describes different types of XSS attacks, including reflected, stored, DOM-based, and induced XSS. It also outlines several existing prevention approaches, such as input validation, output encoding, and firewalls. The document then proposes a method to detect base64-encoded malicious scripts by decoding the input, applying a regular expression to detect attack vectors, and properly escaping any detected scripts. Overall, the document provides an overview of XSS attacks and compares limitations of common prevention techniques, concluding with a proposed approach to enhance defenses against base64 obfuscated XSS scripts.
Building Production Ready Search Pipelines with Spark and MilvusZilliz
Spark is the widely used ETL tool for processing, indexing and ingesting data to serving stack for search. Milvus is the production-ready open-source vector database. In this talk we will show how to use Spark to process unstructured data to extract vector representations, and push the vectors to Milvus vector database for search serving.
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
AI 101: An Introduction to the Basics and Impact of Artificial IntelligenceIndexBug
Imagine a world where machines not only perform tasks but also learn, adapt, and make decisions. This is the promise of Artificial Intelligence (AI), a technology that's not just enhancing our lives but revolutionizing entire industries.
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!SOFTTECHHUB
As the digital landscape continually evolves, operating systems play a critical role in shaping user experiences and productivity. The launch of Nitrux Linux 3.5.0 marks a significant milestone, offering a robust alternative to traditional systems such as Windows 11. This article delves into the essence of Nitrux Linux 3.5.0, exploring its unique features, advantages, and how it stands as a compelling choice for both casual users and tech enthusiasts.
Full-RAG: A modern architecture for hyper-personalizationZilliz
Mike Del Balso, CEO & Co-Founder at Tecton, presents "Full RAG," a novel approach to AI recommendation systems, aiming to push beyond the limitations of traditional models through a deep integration of contextual insights and real-time data, leveraging the Retrieval-Augmented Generation architecture. This talk will outline Full RAG's potential to significantly enhance personalization, address engineering challenges such as data management and model training, and introduce data enrichment with reranking as a key solution. Attendees will gain crucial insights into the importance of hyperpersonalization in AI, the capabilities of Full RAG for advanced personalization, and strategies for managing complex data integrations for deploying cutting-edge AI solutions.
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
HCL Notes and Domino License Cost Reduction in the World of DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-and-domino-license-cost-reduction-in-the-world-of-dlau/
The introduction of DLAU and the CCB & CCX licensing model caused quite a stir in the HCL community. As a Notes and Domino customer, you may have faced challenges with unexpected user counts and license costs. You probably have questions on how this new licensing approach works and how to benefit from it. Most importantly, you likely have budget constraints and want to save money where possible. Don’t worry, we can help with all of this!
We’ll show you how to fix common misconfigurations that cause higher-than-expected user counts, and how to identify accounts which you can deactivate to save money. There are also frequent patterns that can cause unnecessary cost, like using a person document instead of a mail-in for shared mailboxes. We’ll provide examples and solutions for those as well. And naturally we’ll explain the new licensing model.
Join HCL Ambassador Marc Thomas in this webinar with a special guest appearance from Franz Walder. It will give you the tools and know-how to stay on top of what is going on with Domino licensing. You will be able lower your cost through an optimized configuration and keep it low going forward.
These topics will be covered
- Reducing license cost by finding and fixing misconfigurations and superfluous accounts
- How do CCB and CCX licenses really work?
- Understanding the DLAU tool and how to best utilize it
- Tips for common problem areas, like team mailboxes, functional/test users, etc
- Practical examples and best practices to implement right away
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...
Pantallas escaneo Sitio Web
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21. Cross-Site Scripting vulnerabilities w ere verified as executing code on the w eb application. Cross-Site Scripting
occurs w hen dynamically generated w eb pages display user input, such as login information, that is not properly
validated, allow ing an attacker to embed malicious scripts into the generated page and then execute the script on
the machine of any user that view s the site. In this instance, the w eb application w as vulnerable to an automatic
payload, meaning the user simply has to visit a page to make the malicious scripts execute. If successful, Cross -
Site Scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken
for those of a valid user, compromise confidential information, or execute malicious code on end user systems.
Recommendations include implementing secure programming techniques that ensure proper filtration of user-
supplied data, and encoding all user supplied data to prevent inserted scripts being sent to end users in a format
that can be executed.
Execution:
How to verify or exploit the issue.
View the attack string included w ith the request to check w hat to search for in the response. For instance, if
22. "(javascript:alert('XSS')" is submitted as an attack (or another scripting language), it w ill also appear as part of the
response. This indicates that the w eb application is taking values from the HTTP request parameters and using
them in the HTTP response w ithout first removing potentially malicious data.
Implication:
How this vulnerability affects you.
XSS can generally be subdivided into tw o categories: stored and reflected attacks. The main difference betw een
the tw o is in how the payload arrives at the server. Stored attacks are just that...in some form stored on the target
server, such as in a database, or via a submission to a bulletin board or visitor log. The victim w ill retrieve and
execute the attack code in his brow ser w hen a request is made for the stored information. Reflected attacks, on
the other hand, come from somew here else. This happens w hen user input from a w eb client is immediate ly
included via server-side scripts in a dynamically generated w eb page. Via some social engineering, an attacker
can trick a victim, such as through a malicious link or "rigged" form, to submit information w hich w ill be altered to
include attack code and then sent to the legitimate server. The injected code is then reflected back to the user's
brow ser w hich executes it because it came from a trusted server. The implication of each kind of attack is the
same.
The main problems associated w ith successful Cross-Site Scripting attacks are:
Account hijacking - An attacker can hijack the user's session before the session cookie expires and take
actions w ith the privileges of the user w ho accessed the URL, such as issuing database queries and
view ing the results.
Malicious script execution - Users can unknow ingly execute JavaScript, VBScript, ActiveX, HTML, or
even Flash content that has been inserted into a dynamically generated page by an attacker.
Worm propagation - With Ajax applications, XSS can propagate somew hat like a virus. The XSS payload
can autonomously inject itself into pages, and easily re-inject the same host w ith more XSS, all of w hich
can be done w ith no hard refresh. Thus, XSS can send multiple requests using complex HTTP methods
to propagate itself invisibly to the user.
Information theft - Via redirection and fake sites, attackers can connect users to a malicious server of the
attacker's choice and capture any information entered by the user.
Denial of Service - Often by utilizing malformed display requests on sites that contain a Cross-Site
Scripting vulnerability, attackers can cause a denial of service condition to occur by causing the host site
to query itself repeatedly .
Brow ser Redirection - On certain types of sites that use frames, a user can be made to think that he is in
fact on the original site w hen he has been redirected to a malicious one, since the URL in the brow ser's
address bar w ill remains the same. This is because the entire page isn't being redirected, just the frame
in w hich the JavaScript is being executed.
Manipulation of user settings - Attackers can change user settings for nefarious purposes.
23. For more detailed information on Cross-Site Scripting attacks, see the HP Cross-Site Scripting w hitepaper.
Fix:
How to remediate the issue.
For Development:
Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. When
validating user input, verify that it matches the strictest definition of valid input possible. For example, if a certain
parameter is supposed to be a number, attempt to convert it to a numeric data type in your programming language.
PHP: intval("0".$_GET['q']);
ASP.NET: int.TryParse(Request.QueryString["q"], out val);
The same applies to date and time values, or anything that can be converted to a stricter type before being used.
When accepting other types of text input, make sure the value matches either a list of acceptable values (w hite-
listing), or a strict regular expression. If at any point the value appears invalid, do not accept it. Also, do not attempt
to return the value to the user in an error message.
Most server side scripting languages provide built in methods to convert the value of the input variable into correct,
non-interpretable HTML. These should be used to sanitize all input before it is displayed to the client.
PHP: string htmlspecialchars (string string [, int quote_style])
ASP.NET: Server.HTMLEncode (strHTML String)
When reflecting values into JavaScript or another format, make sure to use a type of encoding that is appropriate.
Encoding data for HTML is not sufficient w hen it is reflected inside of a script or style sheet. For example, w hen
reflecting data in a JavaScript string, make sure to encode all non-alphanumeric characters using hex (xHH)
encoding.
If you have JavaScript on your page that accesses unsafe information (like location.href) and w rites it to the page
(either w ith document.w rite, or by modifying a DOM element), make sure you encode data for HTML before w riting
it to the page. JavaScript does not have a built-in function to do this, but many framew orks do. If you are lacking
an available function, something like the follow ing w ill handle most cases:
s = s.replace(/&/g,'&').replace(/"/i,'"').replace(/</i,'<').replace(/>/i,'>').replace(/'/i,''')
24. Ensure that you are alw ays using the right approach at the right time. Validating user input should be done as soon
as it is received. Encoding data for display should be done immediately before displaying it.
For Security Operations:
Server-side encoding, w here all dynamic content is first sent through an encoding function w here Scripting tags
w ill be replaced w ith codes in the selected character set, can help to prevent Cross-Site Scripting attacks.
Many w eb application platforms and framew orks have some built-in support for preventing Cross-Site Scripting.
Make sure that any built-in protection is enabled for your platform. In some cases, a misconfiguration could allow
Cross-Site Scripting. In ASP.NET, if a page's EnableView StateMac property is set to False, the ASP.NET view
state can be used as a vector for Cross-Site Scripting.
An IDS or IPS can also be used to detect or filter out XSS attacks. Below are a few regular expressions that w ill
help detect Cross-Site Scripting.
Regex for a simple XSS attack:
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
The above regular expression w ould be added into a new Snort rule as follow s:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Cross-Site Scripting attempt";
flow :to_server,established; pcre:"/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/i"; classtype:Web-application-
attack; sid:9000; rev:5;)
Paranoid regex for XSS attacks:
/((%3C)|<)[^n]+((%3E)|>)/I
This signature simply looks for the opening HTML tag, and its hex equivalent, follow ed by one or more characters
other than the new line, and then follow ed by the closing tag or its hex equivalent. This may end up giving a few
false positives depending upon how your w eb application and w eb server are structured, but it is guaranteed to
catch anything that even remotely resembles a Cross-Site Scripting attack.
For QA:
Fixes for Cross-Site Scripting defects w ill ultimately require code based fixes. Read the the follow ing links for more
information about manually testing your application for Cross-Site Scripting.
Reference Info:
25. OWASP Cross-Site Scripting Information
https://www.owasp.org/index.php/XSS
Microsoft
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985
Microsoft Anti-Cross Site Scripting Library
https://msdn.microsoft.com/en-us/security/aa973814.aspx
CERT
http://www.cert.org/advisories/CA-2000-02.html
Apache
http://httpd.apache.org/info/css-security/apache_specific.html
SecurityFocus.com
http://www.securityfocus.com/infocus/1768
26. Summary: Insecure Transport: Weak SSL Cipher
Vulnerability ID: 11285
WebInspect has detected support for w eak TLS/SSL ciphers on server https://zero.webappsecurity.com:443/ .
The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a mechanism to help
protect authenticity, confidentiality and integrity of the data transmitted betw een a client and w eb server. The
strength of this protection mechanism is determined by the authentication, encryption and hashing algorithms,
collectively know n as a cipher suite, chosen for the transmission of sensitive information over the TLS/SSL channel.
Most Web servers support a range of such cipher suites of varying strengths. Using a w eakcipher or an encryption
key of insufficient length, for example, could allow an attacker to defeat the protection mechanism and steal or
modify sensitive information.
If misconfigured, a w eb server could be manipulated into choosing w eak cipher suites. Recommendations include
updating the w eb server configuration to alw ays choose the strongest ciphers for encryption.
Execution:
How to verify or exploit the issue.
Each w eak cipher w as enumerated by establishing an SSL connection w ith the target host and specifying the
cipher to test in the Client Hello message of the SSL handshake.
Implication:
How this vulnerability affects you?
A w eak encryption scheme can be subjected to brute force attacks that have a reasonable chance of succeeding
using current methods and resources. An attacker may be able to execute a man-in-the-middle attack w hich w ould
allow them to intercept, monitor and tamper w ith sensitive data.
Fix:
How to remediate the issue.
Disable support for w eak ciphers on the server. Weak ciphers are generally defined as:
Any cipher w ith key length less than 128 bits
Export-class cipher suites
NULL ciphers
Ciphers that support unauthenticated modes
Ciphers assessed at security strenghts below 112 bits
All RC4 ciphers
27. NOTE: Three-key Triple DES is assessed at a security strength of 112 bits and is an approved encryption algorithm
by NIST for use in SSL/TLS communications. Tw o-key Triple DES how ever, should be disabled as it is assessed
at a security strength of 80 bits and has been deprecated.
The follow ing ciphers supported by the server are w eak and should be disabled:
SSL2_RC4_128_WITH_M D5 (0x10080)
SSL2_RC4_128_EXPORT40_WITH_MD5 (0x20080)
SSL2_RC2_CBC_128_CBC_WITH_M D5 (0x30080)
SSL2_RC2_CBC_128_CBC_WITH_M D5 (0x40080)
SSL2_DES_64_CBC_WITH_M D5 (0x60040)
SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x700c0)
SSL_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
SSL_RSA_WITH_RC4_128_M D5 (0x4)
SSL_RSA_WITH_RC4_128_SHA (0x5)
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
SSL_RSA_WITH_DES_CBC_SHA (0x9)
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14)
SSL_DHE_RSA_WITH_DES_CBC_SHA (0x15)
TLS_RSA_EXPORT_WITH_RC4_40_M D5 (0x3)
TLS_RSA_WITH_RC4_128_M D5 (0x4)
TLS_RSA_WITH_RC4_128_SHA (0x5)
TLS_RSA_EXPORT_WITH_RC2_CBC_40_M D5 (0x6)
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
TLS_RSA_WITH_DES_CBC_SHA (0x9)
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14)
TLS_DHE_RSA_WITH_DES_CBC_SHA (0x15)
The list above includes ciphers that enable conditions for FREAK (Factoring RSA Export Keys) attacks. FREAK
attacks could allow man-in-the-middle attackers to trick vulnerable clients into choosing w eak export-class RSA
cipher to communicate w ith the target server, even if the client is not configured to offer one. This attack is identified
by CVE-2015-0204.
Follow ing export-class ciphers should be removed from the target server configuration to prevent FREAK attacks:
SSL_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
28. TLS_RSA_EXPORT_WITH_RC4_40_M D5 (0x3)
TLS_RSA_EXPORT_WITH_RC2_CBC_40_M D5 (0x6)
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
For Apache, modify the follow ing lines in httpd.conf or ssl.conf:
o SSLCipherSuite
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:!RC4:!RC2:!DES:+HIGH:+MEDIUM
For IIS, please refer to Microsoft Know ledge Base Articles:
o Article ID: 187498
o Article ID: 245030 and
o Security Guidance for IIS
o Article ID: 2868725
For other servers, please refer to vendor specific documentation.
The follow ing ciphers supported by the server should provide adequate protection and may be left enabled:
SSL_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
PCI Security Standards Council:
PCI DSS v3.1
CVE
CVE-2013-2566
NIST
29. NIST Special Publication 800-131A
Microsoft:
Knowledge Base Article ID: 2868725
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
RC4:
New RC4 Attack
Summary: Insecure Transport: Weak SSL Protocol
Vulnerability ID: 11286
WebInspect has detected support for w eak SSL 2.0 protocol on the target server
https://zero.webappsecurity.com:443/.
The Transport Layer Security (TLS) protocol and the Secure Sockets Layer (SSL) protocol provide a protection
mechanism to ensure authenticity, confidentiality and integrity of the data transmitted betw een a client and w eb
server.
The TLS/SSL protocol has undergone various revisions resulting in periodic version updates. Each new revision
w as designed to address the security w eaknesses discovered in the previous versions. Use of insecure protocol
versions w ill w eaken the strength of the transport protection and could allow an attacker to compromise, steal or
modify sensitive information. Correctly configuring the w eb server to use the most secure protocol is highly
recommended.
Having SSL 2.0 enabled on the server also makes it vulnerable to DROWN Attack. A server is show n to be
susceptible to DROWN if it either:
Allow s SSL 2.0 connections or
Shares its private key w ith any other server that supports SSL 2.0
Simply supporting SSL 2.0 or sharing the server's private key w ith any another server that supports SSL 2.0 makes
the target server vulnerable to DROWN. The vulnerability allow s an attacker to decrypt any modern TLS connection
to eavesdrop and steal information exchanged betw een the clients and the target server. The attack is identified
by CVE-2016-0800.
30. Execution:
How to verify or exploit the issue.
Each w eak protocol w as enumerated by establishing an SSL connection w ith the target host and specifying the
protocol to test in the Client Hello message of the SSL handshake.
The list of supported SSL protocols can be obtained by running the server analyzer tool from HP security toolkit
against the traget w eb application.
Implication:
How this vulnerability affects you.
SSL 2.0 may exhibit follow ing security w eaknesses:
no protection against man-in-the-middle attacks
same key used for authentication and encryption
w eak message authentication control
no protection against TCP connection closing
makes the server vulnerable to DROWN Attack
These properties can allow an attacker to intercept, modify and tamper w ith sensitive data.
Fix:
How to remediate the issue.
1. Disable support for w eak protocols on the server.
For Apache, modify the follow ing lines in httpd.conf or ssl.conf:
o SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1
For IIS, please refer to Microsoft Know ledge Base Articles:
o 187498
o 245030
o Security Guidance for IIS
For other servers, please refer to vendor specific documentation.
2. Check SSL configurations on all servers that interact w ith the target server including email servers etc. to ensure
that SSL 2.0 is disabled on all of them. If a server has to be SSL 2.0 enabled then please ensure that they do not
share the same private key w ith any other server.
31. The follow ing protocols supported by the server should provide adequate protection:
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
PCI Security Standards Council:
https://www.pcisecuritystandards.org/pdfs/pcissc_assessors_nl_2008-11.pdf
Microsoft:
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
The DROWN Attack
Summary: Insecure Transport: Weak SSL Protocol
Vulnerability ID: 11378
WebInspect has detected support for SSL 3.0 protocol on the target server. The Secure Sockets Layer (SSL)
protocol provide a protection mechanism to better protect authenticity, confidentiality and integrity of the data
transmitted betw een a client and w eb server. The TLS/SSL protocol has undergone various revisions resulting in
periodic version updates. Each new revision w as designed to address the security w eaknesses discovered in the
previous versions. SSL 3.0 version is considered insecure because of lack of strong cipher suite support. It either
uses RC4 cipher, w hich is prone bias attacks or uses Cipher Block Chaining (CBC) mode cipher, w hich enables
condition for POODLE (Padding Oracle On Dow ngraded Legacy Encryption) attacks.
Use of insecure protocol versions w ill w eaken the strength of the transport protection and could allow an attacker
to compromise, steal or modify sensitive information. Correctly configuring the w eb server to use the most secure
protocol is highly recommended.
Execution:
How to verify or exploit the issue.
32. The list of supported SSL/TLS protocols can be obtained by running the server analyzer tool from HP security
toolkit supplied w ith HP WebInspect against the target server.
Implication:
How this vulnerability affects you.
Weak TLS/SSL protocols may exhibit any or all of the follow ing properties:
No protection against man-in-the-middle attacks
Same key used for authentication and encryption
Weak message authentication control
No protection against TCP connection closing
These properties can allow an attacker to intercept, modify and tamper w ith sensitive data.
Fix:
How to remediate the issue.
Disable support for the SSL 3.0 protocol on the server. Instead, TLSv1.1 and above should be used.
For Apache, modify the follow ing lines in the server configuration:
o SSLProtocol ALL –SSLv2 -SSLv3 -TLSv1
For Nginx, modify the follow ing lines in server configuration:
o ssl_protocols TLSv1.1 TLSv1.2;
For IIS, please refer to Microsoft Know ledge Base Articles:
o https://technet.microsoft.com/library/security/3009008
For other servers, please refer to vendor specific documentation:
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
PCI Security Standards Council:
https://www.pcisecuritystandards.org/pdfs/pcissc_assessors_nl_2008-11.pdf
Microsoft:
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
33. Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
CVE-2014-3566
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
This POODLE bites: exploiting the SSL 3.0 fallback
https://www.openssl.org/~bodo/ssl-poodle.pdf
TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00l
Summary: Insecure Transport: Weak SSL Protocol
Vulnerability ID: 11395
The Transport Layer Security (TLS) protocol provides a protection mechanism to better protect authenticity,
confidentiality and integrity of the data transmitted betw een a client and a w eb server. The TLS protocol has
undergone various revisions resulting in periodic version updates. Each revision tries to address security w eakness
in prior versions and incorporate support for the latest in security measures. It is strongly recommended to use the
latest version of the available protocol, w henever possible.
TLS 1.0 is considered insecure as it lacks support for strong ciphersuites and is know n to be plagued by several
know n vulnerabilities. It either uses RC4 cipher, w hich is prone to bias attacks or uses Cipher Block Chaining
(CBC) mode cipher, w hich enables condition for POODLE (Padding Oracle On Dow ngraded Legacy Encryption)
attacks.
NIST Special Publication 800-52 Revision 1 no longer considers TLS 1.0 as strong cryptography. TLS 1.0 is also
no longer in compliance w ith PCI DSS v3.1 requirements. PCI does not consider TLS 1.0 to be adequate to protect
cardholder data and has deprecated its use starting June 2016.
Update: PCI DSS has extended deadline for migration to TLS1.1 or above to June 30, 2018. However, an
early migration is recommended to ensure security of your data and applications.
Use of insecure protocol versions w ill w eaken the strength of the transport protection and could allow an attacker
to compromise, steal or modify sensitive information. Configuring the w eb server to use the most secure protocol,
TLS 1.1 or TLS 1.2 is highly recommended.
34. Implication:
How this vulnerability affects you.
Use of a w eakprotocol such as TLS 1.0 leaves the connection vulnerable to man-in-the-middle attacks. This w ould
allow the attacker to read and modify data on a secure TLS connection, thus compromising user security and
privacy. Its use w ould also limit the use of strong cipher suites that help protect data integrity and confidentiality.
Fix:
How to remediate the issue.
Disable support for the TLS 1.0 protocol on the server. Both NIST 800-52 and PCI DSS v3.1 strongly recommend
upgrade to the latest version of TLS available, TLS 1.2. Or, at a minimum an upgrade to TLS 1.1.
For Apache, modify the follow ing lines in the server configuration
o SSLProtocol ALL –SSLv2 -SSLv3 -TLSv1
For Nginx, modify the follow ing lines in server configuration:
o ssl_protocols TLSv1.1 TLSv1.2;
For IIS, please refer to Microsoft Know ledge Base Articles:
o https://technet.microsoft.com/library/security/3009008
For other servers, please refer to vendor specific documentation.
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
NIST:
NIST SP 800-52 Revision 1
PCI Security Standards Council:
PCI DSS v3.1
Migrating from SSL and Early TLS
PCI SSC FAQ on impending revisions to PCI DSS, PA-DSS to address SSL protocol vulnerability
Microsoft:
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
Security Guidance for IIS
35. Apache:
SSL/TLS Strong Encryption: FAQ
CVE-2014-8730
CVE-2014-8730
POODLE Vulnerability Expands Beyond SSLv3 to TLS 1.0 and 1.1
https://www.globalsign.com/en/blog/poodle-vulnerability-expands-beyond-sslv3-to-tls/
TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00l
Summary: Insecure Transport: Weak SSL Cipher
Vulnerability ID: 11480
Logjam is an attack against the Diffie-Hellman key exchange protocol used in TLS. Diffie-Hellman is a key
exchange protocol used w ithin SSL/TLS connections to securely exchange cryptographic keys over a public
channel.The Logjam attack affects all servers that support export grade DHE (DHE_EXPORT) ciphersuites. It
attacks a flaw in the TLS protocol that allow s the attacker to dow ngrade a TLS connection using a non
DHE_EXPORT ciphersuite to a vulnerable connection using a 512 bit DHE_EXPORT ciphersuite. This enables a
man in the middle attacker to easily decrypt and eavesdrop on the TLS connection.
WebInspect has determined that the target server is vulnerable to Logjam attack as it supports the follow ing
DHE_EXPORT ciphers:
Execution:
How to verify or exploit the issue.
A list of supported ciphers by this server can be obtained by running ServerAnalyzer tool from the WebInspect
toolkit. Note the presence of “DHE_EXPORT“ in the list of supported ciphersuites.
Implication:
How this vulnerability affects you.
A dow ngraded TLS connection allow s the Logjam attacker to easily read and modify any data passed over that
TLS connection.
Fix:
How to remediate the issue.
Disable support for cipher suites using DHE_EXPORT key exchange.
36. o For Apache - Modify SSLCipherSuite parameter to disable all DHE_EXPORT ciphers.
o For Ngnix - Modify ssl_ciphers in server configuration to disable all DHE_EXPORT ciphers.
o For IIS - Please refer to the follow ing know ledge base article :
https://support.microsoft.com/en-us/kb/245030
Enable support for Elliptic-Curve Diffie-Hellman (ECDHE) key exchange.
Reference Info:
1. CVE-2015-4000
2. Schneier on Security
3. The Logjam Attack
4. Logjam: TLS vulnerabilities(CVE-2015-4000)