Your browser doesnt support Xml Http Request – but the test passed ! errrrrorrr??

1. Open / Start QTP
2. Right click on the Menu toolbar (File  Edit View Insert ….)
3. Select “Customize”
4. Click on the “Toolbars” tab
5. then Click on “Restore All” button at the lower right hand side.

Wallah ! now All iz Well !

The vulnerability affects Windows 2000, XP and Server 2003-based systems, Microsoft said in a security advisory dated March 1.

Microsoft said that the vulnerability in VBScript could allow remote code execution of computers. “If a malicious Web site displayed a specially crafted dialog box and a user pressed the F1 key, arbitrary code could be executed in the security context of the currently logged-on user,” Microsoft said on its Web site, “On systems running Windows Server 2003, Internet Explorer Enhanced Security Configuration is enabled by default, which helps to mitigate against this issue.” Windows Vista, Windows 7, and Windows Server 2008 are not affected.

The advisory includes several workarounds, including advice to avoid pressing the F1 key when prompted by a Web site.

It also suggests restricting access to the Windows Help System, setting Internet and Local intranet security zone settings to “high” to block ActiveX Controls and Active Scripting, and configuring Internet Explorer to prompt before running Active Scripting or disable Active Scripting in the Internet and Local intranet security zone.

Microsoft complained in its advisory and a statement that the vulnerability was not responsibly disclosed.

Three of the notices relate to critical vulnerabilities, with the two just classed as “moderate”, while all of which could potentially allow a hacker to executive arbitrary code.

It is understood the US-CERT department is advising Firefox users to upgrade to version 3.0.18, 3.5.8 or 3.6. Thunderbird users have been told to upgrade to 3.0.2, with SeaMonkey users also advised to upgrade to 2.0.3.

The notices come after Mozilla employee Jess Ruderman wrote in a security blog post last week the company has begun to deliver updates and notices about security problems more quickly.

It has been suggested that the Download Manager is an ActiveX script that is widely used to install a variety of software and patches across Adobe’s network.

An Israeli security researcher Aviv Raff has identified the flaw which allows a third party application to be installed on the remote machine if users click on a link.

In his blog Raff says that despite informing Adobe the company downplayed the risk.

“While it is true that the Adobe Download Manager is removed upon computer restart, the user, who has just updated their Adobe product (usually without the requirement to restart the computer after the update), is still exposed to forced automatic installation until they restart their computer.

“This specific design flaw does indeed force installation of the latest version of Adobe products. But, what if there is a zero-day flaw in an Adobe product, and you have decided to remove it from your system because of that zero-day?

“An attacker can force you to automatically download and install the vulnerable Adobe product, and then exploit the zero-day vulnerability in that product.”

A recent report from Scansafe found that based on more than a trillion web requests processed in 2009, the use of malicious PDF files exploiting flaws in Adobe Reader/Adobe Acrobat not only outpaced the use of Flash exploits, but also, grew to 80pc of all exploits the company encountered throughout the year.

“This is the kind of scenario that’s common when skilled, motivated attackers are going after select targets.

And yes, you do get a big dialog box when you are forced to download the software. Like this will really matter to the attacker, when all he wants is to get his malicious software on your machine,” Raff said.

Features of soapUI

The soapUI is designed to simplify the testing of your Web services; I also find it useful for interacting with third-party Web services to get a better idea of what to expect in the response, as well as what to include in the response. It was especially useful in a recent project utilizing ChannelAdvisor Web services. Using soapUI, I was able to figure out the data expected in request objects.

SoapUI is accessible to both technical and nontechnical persons. The easy-to-use graphical interface makes it simple to work with WSDL and SOAP-based Web services. It provides a Web service client that can automatically generate Web service requests and tests.

With the tool, you can work with XML and its many variations like WSDL. WSDL is easily imported via its URL, along with a great viewer for navigating and inspecting the WSDL source.

SoapUI offers extensive security features, which include Web service authentication and WS-Security. One of the cool features I like is the excellent SOAP monitor support; it allows you to easily monitor and analyze traffic.

The user interface is powerful; the soapUI tool also provides a command-line option. It allows you to run your tests via the command line, thus it can be easily automated in batch files.

Putting soapUI to work

Figure A provides a look at the soapUI interface with a new project created to access the Amazon S3 Web service. It includes the generation of a new request for the Web service’s CopyObject method. A new request is generated by right-clicking a method name (in the left side of the IDE) and selecting New Request.

With the request generated, you can fill in the necessary data and submit the request via the green Play button in the upper left of the request window. A validation option is available as well to ensure the request XML is valid before you try to submit it. Once you submit a request, you can view the results to see the response (if there is one) from the Web service call.

Figure A

The ability to create mock objects is available within soapUI. It allows you to test a Web service without actually connecting to it. The feature is available by right-clicking a method.

In addition to running a request, you may create a new assertion for testing. The left pane (navigation area) of the IDE includes a node for Tests. This allows you to create new tests and test scripts for validation proper Web service execution.

Integration

SoapUI easily integrates with IDEs and other tools to become a part of your development process. The list of IDEs includes Maven, NetBeans, IntelliJ IDEA, JBoss, and Eclipse. The other tools include code generation and WS-I options. Tools may be associated with soapUI via the Preferences window, as shown in Figure B, which include the configuration for the .NET wsdl.exe tool.

Figure B

Getting soapUI

The soapUI tool is built with Java. The necessary Java files may be installed when soapUI is installed. Its reliance on Java means it can run on many platforms. The download page includes Windows installation files as well as tar files for other systems.

A great aspect of soapUI is its cost — free! Well, the Basic version is available at no cost. A Pro version is available with a one year license for $349. The professional version includes everything that’s in the Basic version, along with product support and additional features for testing such as refactoring, data sources, and drag-and-drop editing.

Don’t forget to test

Testing is an important aspect of every development project. It seems common to test a Web service as part of a bigger system via how the Web service is accessed. However, it is important to fully test the service itself. The soapUI tool allows you to easily write test suites and test cases.

A better way

The soapUI tool provides a great way to interact with and test Web services whether they are your own or third-party offerings. It is a nice alternative to other options I’ve used, such as the built-in features of Visual Studio or hand-coding SOAP requests

In designing Chromium, we’ve been working hard to make the browser as secure as possible. We’ve made strong improvements with the integrated sandboxing and our up-to-date user base. We’re always looking to stay on top of the latest browser security features. We’ve also worked closely with the broader security community to get independent scrutiny and to quickly fix bugs that have been reported.

Some of the most interesting security bugs we’ve fixed have been reported by researchers external to the Chromium project. For example, this same origin policy bypass from Isaac Dawson or this v8 engine bug found by the Mozilla Security Team. Thanks to the collaborative efforts of these people and others, Chromium security is stronger and our users are safer.

Today, we are introducing an experimental new incentive for external researchers to participate. We will be rewarding select interesting and original vulnerabilities reported to us by the security research community. For existing contributors to Chromium security — who would likely continue to contribute regardless — this may be seen as a token of our appreciation. In addition, we are hoping that the introduction of this program will encourage new individuals to participate in Chromium security. The more people involved in scrutinizing Chromium’s code and behavior, the more secure our millions of users will be.

Such a concept is not new; we’d like to give serious kudos to the folks at Mozilla for their long-running and successful vulnerability reward program.

Any bug filed through the Chromium bug tracker (under the template “Security Bug”) will qualify for consideration. As this is an experimental program, here are some guidelines in the form of questions and answers:

Q) What reward might I get?

A) As per Mozilla, our base reward for eligible bugs is $500. If the panel finds a particular bug particularly severe or particularly clever, we envisage rewards of $1337. The panel may also decide a single report actually constitutes multiple bugs. As a consumer of the Chromium open source project, Google will be sponsoring the rewards.

Q) What bugs are eligible?

A) Any security bug may be considered. We will typically focus on High and Critical impact bugs, but any clever vulnerability at any severity might get a reward. Obviously, your bug won’t be eligible if you worked on the code or review in the area in question.

Q) How do I find out my bug was eligible?

A) You will see a provisional comment to that effect in the bug entry once we have triaged the bug.

Q) What if someone else also found the same bug?

A) Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report.

Q) What about bugs present in Google Chrome but not the Chromium open source project?

A) Bugs in either build may be eligible. In addition, bugs in plugins that are part of the Chromium project and shipped with Google Chrome by default (e.g. Google Gears) may be eligible. Bugs in third-party plugins and extensions are ineligible.

Q) Will bugs disclosed publicly without giving Chromium developers an opportunity to fix them first still qualify?

A) We encourage responsible disclosure. Note that we believe responsible disclosure is a two-way street; it’s our job to fix serious bugs within a reasonable time frame.

Q) Do I still qualify if I disclose the problem publicly once fixed?

A) Yes, absolutely. We encourage open collaboration. We will also make sure to credit you in the relevant Google Chrome release notes and nominate you for the Google Security “thank you” section.

Q) What about bugs in channels other than Stable?

A) We are interested in bugs in the Stable, Beta and Dev channels. It’s best for everyone to find and fix bugs before they are released to the Stable channel.

Q) What about bugs in third-party components?

A) These bugs may be eligible (e.g. WebKit, libxml, image libraries, compression libraries, etc). Bugs will be ineligible if they are part of the base operating system as opposed to part of the Chromium source tree. In the event of bugs in a component shared with other software, we are happy to take care of responsibly notifying other affected parties.

Q) Who determines whether a given bug is eligible?

A) The panel includes Adam Barth, Chris Evans, Neel Mehta, SkyLined and Michal Zalewski.

Q) Can you keep my identity confidential from the rest of the world?

A) Yes. If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However — at your discretion, we can credit the bug to “anonymous” and leave the bug entry private.

Q) No doubt you wanted to make some legal points?

A) Sure. We encourage participation from everyone. However, we are unable to issue rewards to residents of countries where the US has imposed the highest levels of export restriction (e.g. Cuba, Iran, North Korea, Sudan and Syria). We cannot issue rewards to minors, but would be happy to have an adult represent you. This is not a competition, but rather an ongoing reward program. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon local law.

We look forward very much to issuing our first reward and featuring it on our releases blog. We’re happy to take questions at security@chromium.org. Alternatively, feel free to leave a comment. We will update this blog post with answers to any popular questions.

Finally, if you’re interested in helping out Chromium security on a more permanent basis, we have open positions.

Posted by Chris Evans, Google Chrome Security

Software bugs are notoriously difficult to eradicate. Traditional quality assurance techniques like testing and software inspections (sometimes called code reviews) find serious bugs, but too many bugs slip through.

This is of particular concern for embedded software developers because embedded software works behind the scenes in ways that users take for granted; in some cases a user’s safety may depend on the correct functioning of the software. Corrective actions—like rebooting or updating the software—are disruptive or even impossible.

The Zune bug where an infinite loop occurred because the device was unprepared for a leap year, is a recent example of a simple embedded software bug that rendered a device useless. In this case, users were deprived of their music for 24 hours. In safety-critical devices like medical devices and spacecraft, similar bugs have led to extensive financial losses, injuries, and even deaths.

Many tools and techniques have been applied to cut the number of bugs in embedded software. Some reduce the odds of a bug being created, while others detect bugs before software is shipped.

These tools and techniques are often complementary, and therefore suited to a defense-in-depth approach where they are applied together. Traditional techniques are increasingly supplemented with the use of static analysis tools and the adoption of coding rules.

The role of static analysis

A static analysis tool is like an automatic reviewer for your code. It reads the source code (without executing it) and looks for cases where it will behave in an undesirable manner—for example, dereferencing a null pointer, dividing a number by zero, or overflowing a memory buffer.

Static analysis tools do not depend on sample input—they can infer the software’s behavior based on just the source code. When a bug is found, the tool reports its location to a software engineer, along with the information needed to diagnose the problem.

Since they do not depend on sample input, static analysis tools can investigate program behavior in corner cases that are not anticipated by testers and human inspectors.

While no tool can find all bugs, modern static analysis tools generate valuable results with minimal false positives, even for projects with millions of lines of code.

Coding Rules and The Power of Ten

Software engineers have long argued about issues like code layout and naming conventions. Coding rule efforts like Gerard Holzmann’s “Power of Ten” and the Motor Industry Software Reliability (MISRA) guidelines for C and C++ are more principled, representing a codification of “best practices” for embedded software development.

They focus on improving software by making it harder to create (and easier to spot) bugs. These rules forbid constructs that are confusing, complex, or subject to varying interpretations by human readers and compilers.

The resulting code is more portable and predictable. Bugs are forced to sit in plain sight instead of hiding behind intricate constructs, and therefore more likely to spotted by software writers, inspectors, and analysis tools.

Some projects may be put off by the effort required to learn and apply a large number of rules (the MISRA C guidelines include 141 rules). To assuage such concerns, Gerard Holzmann, of JPL’s Laboratory for Reliable Software, developed the Power of Ten rules.

These ten rules were chosen to deliver the most bang for the buck: the list is short enough to memorize, but covers many sources of bugs in embedded software. Here’s a synopsis of the Power of Ten rules (full details are available at spinroot.com):

1. Restrict to simple control flow constructs. Do not use goto statements, setjmp, longjmp, or recursion.

2. Give all loops a fixed upper-bound.
3. Do not use dynamic memory allocation after initialization.
4. Limit functions to no more than 60 lines of text.
5. Use minimally 2 assertions for every function of more than 10 lines.
6. Declare data objects at the smallest possible level of scope.
7. Check the return value of all non-void functions, and check the validity of all function parameters.
8. Limit the use of the preprocessor to file inclusion and simple macros.
9. Limit the use of pointers. Use no more than 1 level of dereferencing per expression.
10. Compile with all warnings enabled, in pedantic mode, and use one or more modern static source code analyzers.

Reinforcing each other

Coding rules and static analysis tools are most effective when they work together. In addition to reporting bugs like null pointer dereferences, static analysis tools can flag violations of coding rules.

This automates much of the work of checking compliance with rules, freeing inspection teams to focus on higher-level concerns such as algorithm design or meeting project requirements.

Our tools, for example, come with built-in support for the Power of Ten rules. It is one of several tools used at JPL to check coding rule compliance and to search for bugs in software being developed for upcoming missions.

Coding rules can also make analysis tools more effective. The Power of Ten rules discourage the use of features—such as recursion and indirect functions—that make it more difficult for static analysis tools to accurately infer a program’s behavior. (Human software inspectors will appreciate the clarity and simplicity of the code too.)

Conclusion

To reduce bugs in embedded software, complement your existing code quality practices by adopting appropriate coding rules and using a modern static analysis tool. The Power of Ten rules are a short but effective set of rules that are easy to adopt. Select a static analysis tool that works with your coding rules so that engineers can see rule violations alongside other problems detected by the tool.

Michael McDougall is a GrammaTech Senior Scientist. Dr. McDougall received a B.Sc. in Mathematics and Computer Science from McGill University in 1997 and a PhD in Computer Science from the University of Pennsylvania in 2005. His graduate work focused on applying formal reasoning to problems in software engineering and security. Since joining GrammaTech, he has led research projects on the use of software analysis and visualization techniques to achieve high-quality software.

There are 2 ways to Test if Perl is working properly on your system.

1. Webserver

welcome.pl:

---------------------
#!/usr/bin/perl 
# 
# =========== 
# helloworld.pl 
# =========== 
# 
print "content-type:text/html\n\n";
print "<html>\n";
print "<head>\n";
print "<title>Hello World</title>\n";
print "</head>\n";
print "<body>\n";
print "<b>Hello World!</b><br>\n";
print "</body>\n";
print "</html>\n";
# 
# 

-----------------------------------------
Save it and run it by http://your webserver/myscript.pl

2. Shell

myscipt2.pl:
-----------------------
#!/usr/bin/perl
print "Hello World.\n";
----------------------

run from shell like 

perl myscript2.pl

it will print a line saying Hello World.

Here is my checklist for Activesync so that you can make sure all is well:

You need to make sure that you have Exchange Server 2003 Service Pack 2 Installed – http://www.microsoft.com/downloads/details.aspx?FamilyID=535BEF85-3096-45F8-AA43-60F1F58B3C40&displaylang=en

Open Up Exchange System Manager – Start, Programs, Microsoft Exchange, System Manager.  Expand Servers, Right-Click your server and choose properties.  This will display whether you have SP2 installed or not.

If you have installed SP2, check on https://testexchangeconnectivity.com running the Exchange Activesync check.  You may need to tick the Ignore Trust for SSL check box if you have a self-signed certificate as these always fail.

Ensure that port 443 is open and forwarded on your firewall to your Exchange server.

Please check and mirror the settings below – Open up IIS and expand the default website then Click on the Directory Security Tab:

Exchange Virtual Directory
·         Authentication = Integrated & Basic
·         Default Domain = NETBIOS domain name – e.g., yourcompany
·         Realm = yourcompany.com
·         IP Address Restrictions = Granted Access
·         Secure Communications = Require SSL NOT ticked

Microsoft-Server-Activesync Virtual Directory
·         Authentication = Basic
·         Default Domain = NETBIOS domain name – e.g., yourcompany
·         Realm = NETBIOS name
·         IP Address Restrictions = Granted Access
·         Secure Communications = Require SSL NOT ticked

Then issue IISRESET from Start, Run

Make sure that the name on the certificate that you are using matches the FQDN that you are connecting to e.g., mail.microsoft.com.  If it does not match, either re-issue the certificate if you created it yourself, or re-key the certificate from your SSL certificate provider.

Ensure that the IP for the Default Website is set to All Unassigned

Ensure that Forms Based Authentication is NOT turned on under HTTP Virtual Server under Exchange Protocols.  If it is  read http://support.microsoft.com/kb/817379

ASP.NET should be set to version 1.1 for all virtual directories listed above.