How to make Internet Explorer 8+ run in compatibility mode

inShare1

I know it might come as a surprise to many of you, but Internet Explorer 10 is AWESOME. It is the fastest and the most standards compliant version of the most hated browser in the world.
I always think if Microsoft had done this about 3 years ago it would have been the most popular browser in the world.

Now getting to the point, if you are a web developer or designer  like me and are using Windows 8 and find that your latest work is being rendered properly in your version of Internet Explorer but not on your client’s ridiculously old IE7, and are sitting helpless , thinking of rolling back to Windows XP just for this reason, then worry not, this tutorial is for you !
1. Open up Internet Explorer 10 (The non metro version. I still haven’t tested with the metro version).
2. Press ‘Alt’ key on your keyboard to bring up the top menu. And then go to Tools > Developer Tools. Alternatively you can just press the ‘F12’ key on your keyboard.

3. This will bring up the IE developer tools which looks just like the one in Google Chrome at the bottom.

Web Developer Tools in Internet Explorer 10

You can then click ‘Browser Mode’ and then click on the Internet Explorer version you want to simulate. You can also set the document mode to quirks mode or standards mod from the next drop down .
That’s it. A really short and easy tutorial for a problem that could have been a pain the ass.

OWASP Top 10

2013 Table of Contents 2013 Top 10 List

A1-Injection →

A1-Injection	Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
A2-Broken Authentication and Session Management	Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
A3-Cross-Site Scripting (XSS)	XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
A4-Insecure Direct Object References	A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
A5-Security Misconfiguration	Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
A6-Sensitive Data Exposure	Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
A7-Missing Function Level Access Control	Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
A8-Cross-Site Request Forgery (CSRF)	A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
A9-Using Components with Known Vulnerabilities	Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.
A10-Unvalidated Redirects and Forwards	Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.  CREDITS: https://www.owasp.org/index.php/Top_10_2013-Top_10

The Penetration Testing Report

Penetration test report is not like a normal report as it involves some Nitti gritty, I have tried to comb the web but didn’t find any decent sample to glean from , and I suppose like many out there who will need information on how to write a standard security and penetration test report, well you are here because you stumbled on my report I will not 100% claim ownership of this sample report but I will credit whoever I use their content or opinion at the end of this report. Enjoy

Pre-Engagement Activities

The most important question is why the client is doing the assessment. The answer to this will help you set the test goal and objectives. You will also need to know if you will test just the application or the server will also be included, will you test all parts of the application or just the front-end or the administration back-end, what tests you will make and how intrusive they will be, what time of the day you will do the testing. You will also ask for a single point of contact you can reach in case of emergencies, and so on.

Based on this information, you will have to create a

Penetration Testing Plan

The PTP has to have several sections. If you want to make it good looking, include your company

Cover Page

Usually, we put a short paragraph at the end of the cover page to tag it as confidential. The following is a pretty standard text:

This document is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this disclaimer is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this document is strictly prohibited. If you received this document in error, please notify us immediately by telephone and return the original document to us at the address below. If you have received an electronic copy of the document, please remove it immediately after reading this disclaimer.

 Then, of course, you include a Table of Contents. It is a known fact that C-level executives and decision makers don’t do well with plain text. You need to start with the table of contents, so that they know exactly where to skip to.

Not that it is not obvious from the title of the document, but to be thorough, you would also want to include a

Purpose of This Document

Section. It should clearly state what this document is about. For example, something like this:

The purpose of this document is to describe the details of the penetration test that will be conducted by Ozzy UK Consultants Ltd against the <Name of application> application for <Client>.

 It defines the goal of the test and lists its objectives; it also summarizes the scope of the test, and outlines the scenarios and the tests that will be performed by the testing team.

The next section you need to include would be the

Distribution List

This is simply a table with the people that can read this document. The table can have three columns: Name, Role, and Contact Details. Anyone that should have access to the document should be listed here.

You will also have to include a

Revision History

This is another section that details the changes made on the document by the people that have contributed to it. The columns here are Version, Date, Author, and Comments/Notes.

Then, you have to have a

Project Definition

section. This is another short paragraph, for example:

The Ozzy UK Consultants Ltd team was engaged to test <Name of application> for security issues. The purpose of the test is to determine the level of security of the web application interface.

Now has come the time to secure yourself. Every pentester knows how quickly things change in the security industry, so it is a good idea to include a section about the

Test Limitations

Something like the following should do:

The penetration test provides a snapshot of the current security problems of the system, and it is limited in terms of time and personnel. Therefore, they cannot provide a 100% guarantee that every attack vector has been included, and that the system will stay secure over time.

After you add this ‘limited liability’ section, it is time to list the

Test Goal and Objectives

In this section, you should define the goal of the test (remember those talks you had with the client?) and ‘bullet’ the test objectives. Here is a sample:

The goal of the test is to find possible vulnerabilities, related to the Web application and verify if they are exploitable, provided that a permission to exploit the vulnerability is granted by the client.

To complete this goal, the following objectives are defined:

• Ozzy UK Consultants Ltd will create a threat model for the application. The model will include the assets and the threat agents.
• Ozzy UK Consultants Ltd will inspect the application and map its functionality.
• Based on the application map, Ozzy UK Consultants Ltd will create a detailed test plan with scenarios and test cases, which will be executed against the target application (this document).
• Ozzy UK Consultants Ltd will submit the test plan to <Client> by the <DATE>.
• The security team will test the Web application defined in the test scope for the OWASP top 10 vulnerabilities as described in this test plan.
• The security team will report the progress of the testing to the <Client> SPoC periodically.
•  If vulnerability is found, the security team will verify it after they receive approval from the client SPoC.
•  The security team will produce a conclusion report, which will contain assessment of the security of the Web application, description of the vulnerabilities and recommendations on how to remediate the issues that may be detected during the test. The Conclusion Report will be submitted by <DATE>.
•  The security team will present the conclusion report on <DATE>.

All information obtained during the test will be processed, analyzed and stored in accordance with the Ozzy UK Consultants Ltd security practices and data handling policy.

Good, we finally get to the real stuff. Next you have to define the

Test Scope

It should include several things. First, you have to describe the

Target System

Here, you can use a table with two columns. In the first column, you should have (at least) the following:

• Target System Name
• Target System URL(s)
• Test Type
• Production Environment
• Intrusive Tests
• Client Awareness
• Technology
• Development Framework
• Functionalities
• Login Credentials

The second column should contain the details.

Then, you list the

Tests

You can use bullets to list the test you will perform against the application. The OWASP Top 10 are a good start (See next post for OWASP top 10) . Of course, here you will need to have in mind the specifics of the assessment you are doing.

After that, you describe the

Tools

you will use to perform the tests. Don’t forget to add ‘custom scripts’ to the list, in case you need to code some script for the task.

The final section of the ‘administrative’ part of the PTP is a list of the

IP Addresses

Yet another table with two or three columns: Tester, IP Address, Zone (External/Internet, Internal/VPN).

Now, we are getting to the ‘technical’ part of the testing plan. I would start it with an

Application Map

section. Remember how the CEOs cannot read plain text? Include a picture of the application, describing the process flow and the functions of the application. You may also include a list of the dynamic and static URLs.

To create the application map, you can use Burp Pro, or manually browse through the application and take notes. It is important to include everything that you plan to attack during the test.

When you have a good understanding of the application and the client, you can document the

Threat Models

In this section, you need to describe the reasons an attacker would have to attack the application. You will be putting their shoes on after all. So you will have to have a good understanding of both the client and the application. Of course, you will include hactivism, and skids, but you also need to have specifics – for example, is the application storing sensitive data that could be the target of a hacker, and so on.

The next section that should be included is about the

Scenarios

you will replay. Each scenario should have a short description and a list of the actions a possible attacker would make to take over the application: passively gather information, browse through the application, search for attack vectors, attack as unauthenticated user, brute-force login forms, try as authenticated user, etc.

Then, you have to describe the specific

Tasks

you will have to complete during the test. Each task should have a

• Title: this  is the specific test you will do.
• Task Description: a short description of the test.
• Sub-tasks: the specific actions you will take.
• Task Goal: what you are trying to achieve.
• Task Tools: what you will use.
• Task Risks: how the task can affect the application.

Here is a short example:

Data Validation Testing

Task Description

Test the application for data validation flaws such as XSS, SQL Injection, overflows, format string issues, and HTTP Splitting.

Task Goal

Identify any potential entry point and test user input for injections.

Subtasks

• Manipulate HTTP requests and observe HTTP responses.
• Tamper with user input.
• Test for SQL injections.
• Test for XSS.
• Test for code injections.
• Test for command injections.

Task Tools

• rowser and browser extensions
• Local proxies
• SQL Injection tools (sqlmap)
• w3af

Task Risks

• Application crash.
• Server overload.

And this is the end of the Penetration Testing Plan. As promised, we talked alot about it, but this plan will be the basis of your

Final Report

Actually, most of the PTP goes into the conclusion report. Again, you have the Purpose of This Document, Revision History, Project Definition, Test Goals and Objectives, and Test Scope sections. You can also include a Terminology section, because while the PTP may have been approved by a more technical person, the people that will get the final report may not be that technical.

Then you will have to place a

Summary of Findings

section. Decision makers do not have the time to go through the entire report, so it is important that this one comes first. Here, you will summarize all your findings in a language that a non-technical person can understand. It is always a good idea to include a colored table with the vulnerabilities and the risks they are posing to the application and the company. If you are good at charts, don’t hesitate and include one. A friend of mine, who is a really good manager says that “if it doesn’t have a pie chart, I would not bother looking at it.” As sad as this is, this is the truth. When you are managing a big company, everything becomes a table or a chart to you, so don’t spare them to the readers of your reports.

If you include a table with the vulnerabilities and the risks, take your time and describe them in short paragraphs one by one. You can include a couple of screenshots here to make your point.

When you are done with this, it is time for the

Recommendations

section. After this section, most decision makers would stop reading, so do your best. Take each individual issue and  make a recommendation on how to fix it. Be concise and to the point. This section should be pretty straightforward.

Now, you can start writing for the technical staff. The next section is the

Details on the Findings and the Recommendations

Here, you should include all technical details on how to recreate each issue and how to fix it. Go through the entire process of the test, starting from the information gathering. Go through your actions, describe the findings and issue technical recommendations.

For each test, described in the PTP, provide the details of the tasks and the results of the tests. You can include other documents with the results from the automated tools to keep the report short.

After that, you need to include a

Conclusion

section. It can be one to three paragraphs, summarizing the results of the entire assessment. Basically, in this section, you need to answer to the question that was set as a test goal previously.

If there is data that is short and important enough to go in the report, you can include an

Appendices

section.

And that is it!

Finally

I have to say that I wrote this post in a heart-beat, in a very nice tavern, and my phone is screaming for low battery, so my Internet time for the night is coming to an end. I am not really tracking my time (all the time).  I hack things, and I am good at it.

The report I was writing about is not a vulnerability report from an automated tool. What we do is  not what some companies sell as penetration testing. We do most of the things manually. When we use automated tools (mostly fuzzers), we verify every finding by hand. I have yet to meet the hacker that would use IBM AppScan to hack a site…

And we would give a sample testing plan and a sample report to anyone who asks for it. I am proud of the work we do, and I firmly believe that information has to be shared. I would also welcome suggestions on how to improve it, so don’t be shy and share your thoughts!

CREDITS: http://www.websecuritywatch.com/the-penetration-testing-report/