Security Testing

[sunnyhup]

Security Testing



Herewith, I've consolidated few points about the testing security, that I collected from various documents.

Using the below mentioned general security scenarios you can derive
some general testcases for security.

. Is security adequate?

. Is confidentiality/user privacy protected?

. Is access only successful with 128 bit browsers?

. Does the site prompt for user name and password?

. Does site ask for personal information of children? If so, is it acquired through secure pages

with warning information for parents?

. Are there Digital Certificates, both at server and client?

. Have you verified where encryption begins and ends?

. Are concurrent log-ons permitted?

. Does the application include time-outs due to inactivity?

. Is bookmarking disabled on secure pages?

. Does the key/lock display on status bar for insecure/secure pages?

. Is Right Click, View, Source disabled?

. Are you prevented from doing direct searches by editing content
in the URL?

. If using Digital Certificates, test the browser Cache by enrolling for the Certificate and
completing all of the required security information. After completing the application and
installation of the certificate, try using the <-- BackSpace key to see if that security
information is still residing in Cache. If it is, then any user could walk up to the PC and
access highly sensitive Digital Certificate security information.

. Is there an alternative way to access secure pages for browsers under version 3.0, since SSL

is not compatible with those browsers?

. Do your users know when they are entering or leaving secure
portions of your site?

. Does your server lock out an individual who has tried to access
your site multiple times with invalid login/password information?

à to test security for a web application is general we can do

1. access control checking

2. authorization checking

3. encrypiton and decryption

1 & 2 can be done by the testing team where as the 3rd one is done
by the development team.

If you have more knowledge in how to break the system and write
some virus programs then you can test for that also.

I hope these are the basic things what we test for a web security.

à
. Are there Digital Certificates, both at server and client?

. Have you verified where encryption begins and ends?

I think both these points need a more explanation specially the second one. As per knowledge, once u r in an encryption algorythm u do not have control to check such things as tt simply takes input (encryption bit size, public/private key, data) and gives u output.

[slinkanand]

its gr8.....

i want to add some more points on the above topic>

Software security is about making software behave in the presence of a
malicious attack, even though in the real world, software failures usually
happen spontaneously—that is, without intentional mischief.

The difference between software safety and software security is therefore the presence of an intelligent opponent curved( unauthorized) on breaking the system.

If u are going to break software security, then we should think like attacker, is'in it??

White- and black-box testing and analysis methods both attempt to understand software, but they use different approaches depending on whether the analyst or tester has access to source code. White-box analysis involves analyzing and understanding source code and the design. It’s typically very effective in finding programming errors (bugs when automatically scanning code and flaws when doing risk analysis); in some cases, this approach amounts to pattern matching and can even be automated with a static analyzer (the subject of a future installment of this department). One drawback to this kind of testing is that it might report potential weakness where none actually exists (a false positive). Nevertheless, using static analysis methods on source code is a good technique for analyzing certain kinds of software. Similarly, risk analysis is a whitebox, approach based on a deep understanding of software architecture. Black-box analysis refers to analyzing a running program by probing it with various inputs. This kind of testing requires only a running program and doesn’t use source-code analysis of any kind. In the security example, malicious input can be supplied to the program in an effort to break it. If the program breaks during a particular test, then we might have discovered a security problem. Black box testing is possible even without access to binary code—that is, a program can be tested remotely over a network. If the tester can supply the proper input (and observe the test’s effect), then black-box testing is possible. Any testing method can reveal possible software risks and potential exploits. One problem with almost all kinds of security testing (regardless of whether it’s black or whitebox) is the lack of it—