Although published in mid 2015, SANS “2015 State of Application Security: Closing the Gap” provides interesting insights into:
The latest Cyber Risk Report from HP DVLabs –
Good findings that analyzes:
The number of Web application vulnerabilities that are reported differs significantly from the number that actually exist.
Web application attacks are on the rise, despite the lack of new vulnerabilities being disclosed.
Cross site scripting (aka XSS) is one of the most prevalent web application security issue. In OWASP top 10 for 2010, cross site featured prominently in number 2.
Considering the damage that a successful cross site scripting attack is capable of doing, almost all the successful commercial browsers have tried to provide security features that makes it difficult to execute a successful cross site scripting attack. One of the main ways this attack is carried out is by exploiting the browser’s capability for executing scripts.
Starting Internet Explorer 6 SP1, a new attribute is introduced to the cookies to counter the menace of XSS.
This attribute makes the cookie inaccessible to the scripts, thus stopping malicious script code from executing. The cookies with this attribute set are called HTTP only cookie.
A cookie is set on the client with an HTTP response header.
Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]
The HttpOnly attribute is not case sensitive and it is important to be noted that this feature must be used in coordination with other XSS mitigation to effectively counter XSS, like:
1. Proper input validation.
2. Adequate output encoding whenever any possible user controlled values are rendered back to the browser.
The main class of vulnerability that is detected and patched on Internet Explorer 8 for Windows server include is Remote Code Execution
As of this writing the latest patch came out on Feb 8, 2011 that contained fixes for the a number of issues. Some of these include:
CSS Memory Corruption Vulnerability.
Per CVE-2010-3971 this issue came up because of a vulnerability in the CSharedStyleSheet::Notify function in the Cascading Style Sheets (CSS) parser in mshtml.dll, that is used in Microsoft Internet Explorer 6 through 8 and other products. This vulnerability allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via a self-referential @import rule in a style sheet.
Uninitialized Memory Corruption Vulnerability.
Per CVE-2011-0035 Microsoft Internet Explorer 8 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by accessing an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption.
Almost all the issues reported lead to remote code execution that if successfully exploited could gain the same user rights as the logged-on user. If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
Been a long time I wrote anything in this blog. I am preparing for my CISSP examination and thought that I will share some notes here.
CIA forms the fundamental triad of information security and stands for CONFIDENTIALITY, INTEGRITY and AVAILABILITY.
What is Confidentiality? Any item of importance for an individual/organization (also called an asset) should not be disclosed to anyone who has not be granted explicit rights to it.
What is Integrity? Assurance that the data is free of unauthorized manipulation.
What is Availability? All data and services should be available to the legitimate users each time they need.
Anything and everything we do in information security are always directed towards ensuring that the triad is maintained.
Loss of any one of the three may have extreme legal/reputational impact on the organization/individual.
Microsoft’s threat modeling tool – elaborate TM is a must for any worthwhile application. The video below as well as more details around MS SDL can be found here.
If you are writing Stored Procedures in SQL Server and your code got through a security code review, the chances are bright that you heard the terms “dynamic sql”, “sp_executesql” in the context of SQL Injection.
I found the details of what sp_executesql does in MSDN here. The msdn article starts with a Security note that reads “Run time-compiled Transact-SQL statements can expose applications to malicious attacks, such as SQL injection.”
This procedure, if used correctly, can help mitigate SQL Injection attacks to an extent.
From SQL Server books online, the syntax of sp_executesql looks like:
sp_executesql [ @statement = ] statement
[
{ , [ @params = ] N’@parameter_name data_type [ OUT | OUTPUT ][ ,…n ]’ }
{ , [ @param1 = ] ‘value1’ [ ,…n ] }
]
This method is useful ONLY when you use parameterization correctly and also that this method is no different from dynamic SQL if used with string concatenation. I wrote a quick set of code snippet (copied below) to check this:
The table I used is detailed in my blog entry here. As you can see a well crafted SQL query in the input can still get me the details not meant to be shown.
This can be avoided if I use a properly parameterized implementation of sp_executesql, detailed below.
As you can see when parameterization is used correctly even a crafted value cannot be used to manipulate the results returned by the query.
So use SP_EXECUTESQL does help mitigate the SQL Injection attacks only if parameterization is used properly.
I am trying to understand the internal workings of sp_executesql, for now [:)]!
I am writing some T-SQL code for one of the assignments and am told to watch out for SQL injection as a possible attack vector.
So I took a look around to see what it is and how it really works from a very high level. A good resource to start with SQL Injection (for that matter any attack) is the OWASP.
To try hands on with how dynamic SQL executed using the Execute statement, I created a dummy Database in my local SQL Server instance and created some tables on it. For the purpose of this write up, I will only use one of the tables in the DB that I call “ZipCodes”. There are three dummy records in the table and here is the snapshot:
I created a Stored procedure to get me the record count from this table. Here is the code:
As you see I do not do anything fancy. The Stored procedure takes some parameters and then constructs a sql statement, @SQL which is then executed.
I execute the stored procedure using the following statement to confirm that the procedure is working just fine:
To check whether the stored procedure is validating the input parameters, I inserted the following value as part of in execute statement:
| Exec [dbo].[StoredProcedureToCheckForSQLInjection] ””, ‘ABC’, 123, ‘ZipCodes’` |
Well that irritated my SQL Server and the Stored procedure cried out the following error:
Look at the query that the SP tried to execute (that’s why I used the Print statement in the stored procedure code).
Ok I am on the right track and this procedure is a possible candidate of an injection attacks. I as an attacker will know this looking at the result above which shows that:
1. The Stored procedure is NOT validating the inputs.
2. The stored procedure is doing something by concatenation (Remember that I as an attacker will not have access to the SP code and hence it will be an analysis of the result/error above that will give me these details.)
That’s good news. So can I get all the records in this table? Lets check out using a crafted input that looks like the one below:
Once this query is run, the result that is thrown back is below:
Well that is not what the SP is supposed to do.
Lets check the query that the SP executed to get to the result above:
This is a very very very simple scenario and hopefully all the smart developers out there are not writing code like this in there Stored Procedures. But since I just started and it took me a while to get my query going, I thought of putting this here for reference.
I will comeback to this with more tricky cases. Till then its Happy Learning to me!!
Hi there…I have been looking around for XSS related information and most of the demos I saw are either around displaying an alert in a web page or too advanced for a beginner like me. So as a toddler in the security world I tried to create my own dummy application to see how this attack is executed. What I write below is a documentation of my learning: there may be faults as I am still learning.
So feel free to drop a comment incase anything is not correct, I will surely incorporate any suggestions.
Cross Site Scripting – A little exploit demo to help understand the basics of this attack – I
Application background:
1. We have a simple web forum that uses Form based authentication.
2. The users can comment on the topics discussed by other users.
3. New users visiting this site are required to register by creating a new user name and password.
4. A registered user can: view/write the posts, write comments on the posts and view the comments written by other users.
5. The following code snippet is added to the web.config file for this application. Please note that when request validation is disabled, any content can be submitted to a page; it is the responsibility of the page developer to ensure that content is properly encoded or processed.
Use Scenario:
1. A malicious user registers and logs in to the forum.
2. He picks a topic and clicks on Write comments. Here is what he writes and submits:
This comment will appear as below on the view comments page:
To a normal user this looks like a perfectly harmless piece of text that directs you to another location that has more information around, eh…well Cross Site scripting exploit!
So a good user (let’s call him GoodUser) logs in and clicks on the hyperlink “here” to get some more information around this type of exploits. Here is what he will see:
In our example we used a simple alert statement but in real world scenarios this can contain scripts that can steal your cookie, other important information, etc. These stolen information can be used to impersonate a user, launch a more knowledgeable attack on the application or its user and also can case loss of data that can have financial and reputational implications on both the end user as well as the web site owner.
Hope someone will find this useful to understand how XSS can be exploited. I will posting my rendezvous with XSS.
Happy Reading!
Random Thoughtz 