Web Application Vulnerability Scanning Tools

Web Application Vulnerability Scanning Tools

Nessus
http://www.tenable.com/products/nessus

PortSwigger
https://portswigger.net/

qualys
https://www.qualys.com/

Scan Titan
https://www.scantitan.com/

Nikto
https://cirt.net/Nikto2

CIS (Center for Internet Security) Security benchmark
https://www.cisecurity.org/cis-benchmarks/

Vulnerability Scanning Tools
https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools

HTML a tag target="_blank" vulnerability tabnabbing

HTML a tag target="_blank" vulnerability tabnabbing

window.opener.location = 'https://fakewebsite/facebook.com/PHISHING-PAGE.html';

Solution 1:

<a target="_blank" rel="noopener noreferrer">demo</a>

Solution 2:

var newWnd = window.open();
newWnd.opener = null;

Reference:

https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/

https://medium.com/@ali.dev/how-to-fix-target-blank-a-security-and-performance-issue-in-web-pages-2118eba1ce2f

Nessus - a vulnerability scanner

Nessus is a proprietary vulnerability scanner developed by Tenable Network Security. It is free of charge for personal use in a non-enterprise environment.

Reference:

https://en.wikipedia.org/wiki/Nessus_(software)

Kali Linux is a Debian-derived Linux distribution designed for digital forensics and penetration testing.

Kali Linux is a Debian-derived Linux distribution designed for digital forensics and penetration testing.

Reference:

https://en.wikipedia.org/wiki/Kali_Linux

Web sessions

Web sessions

The most common method is to store a token, or session ID, in a browser cookie. Based on that token, the server then loads the session data from a data store. Over the years, a number of best practices have evolved that make cookie-based web sessions reasonably safe. The OWASP organization lists a number of recommendations aimed at reducing common attacks such as session hijacking or session fixation.

Sticky sessions

https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions/13641836#13641836

Reference:

https://blog.gopheracademy.com/advent-2017/web-sessions-and-users/

https://en.wikipedia.org/wiki/Session_hijacking

https://en.wikipedia.org/wiki/Session_fixation

https://github.com/rivo/sessions

https://en.wikipedia.org/wiki/HTTP_cookie#Cookie_theft_and_session_hijacking

https://en.wikipedia.org/wiki/Cross-site_request_forgery

https://en.wikipedia.org/wiki/Representational_state_transfer#Stateless

https://en.wikipedia.org/wiki/Source_routing

Disable TLS 1.0 and 1.1 in Apache 2.4

Disable TLS 1.0 and 1.1 in Apache 2.4:

# vim /etc/apache2/mods-available/ssl.conf

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Verify if TLS 1.0 and 1.1 are supported:

# openssl s_client -connect mydomain.com:443 -tls1

# openssl s_client -connect mydomain.com:443 -tls1_1

Note: If you get the certificate chain and the handshake you know the system in question supports TLS 1.1.

Reference:

https://serverfault.com/questions/638691/how-can-i-verify-if-tls-1-2-is-supported-on-a-remote-web-server-from-the-rhel-ce

Manually obtaining TLS/SSL certificates from Let's Encrypt

Official build of EFF's Certbot tool for obtaining TLS/SSL certificates from Let's Encrypt.

https://hub.docker.com/r/certbot/certbot/

# certbot certonly --manual --preferred-challenges http --email me@example.com -d mydomain.com

two factor authentication TOTP (RFC 6238) golang example

two factor authentication TOTP (RFC 6238) golang example

package main

import (
        "github.com/pquerna/otp"
        "github.com/pquerna/otp/totp"
        "gopkg.in/redis.v3"

        "bufio"
        "bytes"
        "fmt"
        "image/png"
        //"io/ioutil"
        "log"
        "net/http"
        "os"
        "strconv"
)

var redisClient = redis.NewClient(&redis.Options{
        Addr:     "localhost:6379",
        Password: "", // no password set
        DB:       0,  // use default DB
})

func display(key *otp.Key, data []byte) {
        fmt.Printf("Issuer:       %s\n", key.Issuer())
        fmt.Printf("Account Name: %s\n", key.AccountName())
        fmt.Printf("Secret:       %s\n", key.Secret())
        fmt.Println("Writing PNG to qr-code.png....")
        //ioutil.WriteFile("qr-code.png", data, 0644)
        fmt.Println("")
        fmt.Println("Please add your TOTP to your OTP Application now!")
        fmt.Println("")
}

func promptForPasscode() string {
        reader := bufio.NewReader(os.Stdin)
        fmt.Print("Enter Passcode: ")
        text, _ := reader.ReadString('\n')
        return text
}

func handler(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Home: %s!", r.URL.Path[1:])
}

func writeImage(w http.ResponseWriter, r *http.Request) {
        key, err := totp.Generate(totp.GenerateOpts{
                Issuer:      "Example.com",
                AccountName: "test@example.com",
        })

        if err != nil {
                panic(err)
        }

        // Convert TOTP key into a PNG
        var buf bytes.Buffer

        img, err := key.Image(200, 200)

        if err != nil {
                panic(err)
        }

        png.Encode(&buf, img)

        // display the QR code to the user.
        qrBytes := buf.Bytes()
        display(key, qrBytes)

        if err := redisClient.Set("test@example.com", key.Secret(), 0).Err(); err != nil {
                log.Printf("H: %v\n\n", err)
        }

        w.Header().Set("Content-Type", "image/png")
        w.Header().Set("Content-Length", strconv.Itoa(len(qrBytes)))

        if _, err := w.Write(qrBytes); err != nil {
                log.Println("unable to write image.")
        }
}

func verifyIt(w http.ResponseWriter, r *http.Request) {
        // Now Validate that the user's successfully added the passcode.
        fmt.Println("Validating TOTP...")
        //passcode := promptForPasscode()

        val, err := redisClient.Get("test@example.com").Result()

        if err != nil {
                log.Println("call Result error.")
        }

        valid := totp.Validate(r.URL.Path[3:], val)

        if valid {
                fmt.Fprintf(w, "Good Job: %s.\n", r.URL.Path[3:])
        } else {
                fmt.Fprintf(w, "Wrong code: %s.\n", r.URL.Path[3:])
        }
}

func main() {

        http.HandleFunc("/v/", verifyIt)
        http.HandleFunc("/qr/", writeImage)
        http.HandleFunc("/", handler)

        http.ListenAndServe(":80", nil)
}

Reference:

https://github.com/pquerna/otp

two factor authentication (TFA) implementation

two factor authentication (TFA) implementation

A great pattern that we are seeing for implementing two-factor authentication is to use the TOTP (Time-based One-time Password Algorithm) standard for the second authentication step. What is so cool about TOTP is that it is flexible enough to allow your users to generate their authentication tokens directly on their smart phones using a TOTP app like Google Authenticator or have their tokens sent to their mobile phone via SMS.

Twillio - send SMS cell phone message, voice message and Authentication API for every application

https://www.twilio.com/

GAuthify -Google® Authenticator, SMS, Voice, and Email Two-Factor Authentication in 5 minutes.

https://www.gauthify.com/

Reference:

https://www.twilio.com/blog/2013/04/add-two-factor-authentication-to-your-website-with-google-authenticator-and-twilio-sms.html

https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm#Client_Implementations

https://blog.gopheracademy.com/advent-2013/day-21-two-factor-auth/

The Top 7 Most Reliable SSL Certificate Providers

These days, we do most of our stuff online.  We pay our bills online, we bank online, meet our friends online, shop online, etc.  It is easier, faster and more practical.  It’s also more interactive and real-time. But did you know that there is a certain credential behind this e-commerce technology?  It’s called the SSL Certificate. This article will tackle some of the web’s top providers for SSL Certificates, which include DigiCert, Symantec and Verisign, among others.

What Is an SSL Certificate?

SSL is short for Secure Sockets Layer, which connects your computer to a server that is secure.  SSL is typically used to transfer your credit card details, personal information, banking details and tax information over to another business server.

Lauren Drell, at Mashable, writes that if you have an e-commerce website where you sell anything, then you should secure your site using an SSL certificate.  This is to guarantee to your customers that their information won’t be stolen and that they will not fall victim to identity theft.

The Top SSL Certificate Providers

The thing with SSL certificate providers is that it is usually a matter of who’s popular.  For example, if you have a customer who does not know what Verisign or Comodo is then chances are he would not care about this.  However, to a cautious customer, having his pages authenticated and verified by these companies will go a long way in assuring him that his site is safe.

Offerings from different providers are mostly similar to one another.  Packages offered and the features included in these packages are largely similar as well.

Who are the top SSL certificate providers? This depends on your needs, the features that you want, how popular and trusted these providers are, as well as the prices for the things that you need.  Also, a note of warning:  You might think that certificate authorities are infallible, but they are not.  Look at what happened with DigiNotar in 2011.  On July 10, DigiNotar’s certificates were found to be compromised, leading the company to eventually file for bankruptcy.  Hackers made off with hundreds of certificates, including one for Google that was used for spying in Iran.

Customers for those using DigiNotar were freaked out and even lost some sales until the company got another SSL certificate provider up and running.  They not only wasted time in getting another certificate provider up but they also lost trust while seeing their reputation damaged.  So be sure that you are getting real security by choosing a SSL certificate provider that really works hard to protect and secure the sites under their care.

Here are the best providers to consider:

1. VeriSign
   Now under Symantec’s wing, VeriSign’s authentication business is considered to be one of the most trusted, and is in fact the one used by most of the big brands on the Internet. After its sale, VeriSign has seen a lot of name changes before the current Norton Secured brand name. VeriSign supports up to 256 bit encryption.  Their most expensive package, Secure Site Pro EV costs well over $1,000 but comes with outstanding features such as extended validation, $1.5 million warranty and vulnerability assessment.
2. GeoTrust
   If you think that Verisign is a bit too expensive, then take a look at the packages offered by GeoTrust.  Basic encryption costs $149, while maximum security is guaranteed at only $299.  Expert support, 256-bit encryption and warranty are available for all options.
3. Comodo
   Comodo has SSL certificate solutions for just about anybody: from home offices to businesses, from e-commerce to enterprises. The company also offers up to 256-bit encryption and is trusted by almost all browsers.  They provide unlimited server licenses, expert phone support and a $250,000 warranty.  The Comodo SSL package starts at $64.95 and you can set it up in just minutes.  Their Extended Validation package starts at $359 annually. While being one of the most reputable and trusted certification authorities in the world, you should note that Comodo once figured in a hacking incident, very much similar to the DigiNotar experience, where fake Comodo certificates were used to spy on some people in Iran.
4. Digicert
   DigiCert is trusted by a veritable “who’s who” in the online world.  It is being used by multinational companies such as Microsoft, Yahoo, AT&T, Facebook, Amazon.com, Wikipedia, NASA and Core Logic, among others.  They offer up to 2048 bit SSL certificates at very reasonable prices.  For example, their Wildcard SSL certificates that protect your entire domain cost less than $500!  You could get their cheapest package for as low as $156 per year.
5. Thawte
   Thawte is another low cost SSL certificate provider, with their cheapest plan going for $149 a year and offers up to 256-bit encryption, while their extended validation packages go for less than $600 (even less if you get a two year contract for only $995, or roughly $500 per year).
6. GoDaddy
   Most people know GoDaddy as the biggest domain registration company, but they also offer SSL certificates that go for $69.99 for the Standard package and $89.99 for the Deluxe package.  Both packages can be customized to your needs.  But what gives GoDaddy an edge is that you have access to competent support 24/7.
7. Network Solutions
   Network Solutions claims to have the lowest priced SSL certificates, especially for a multi-year term.  For example, getting the Network Solutions nsProtect Secure Express costs only $49.99 for a four-year term. This is lower than the $54.49 per year at GoDaddy, $132.25 per year at Thawte and $121.00 per year at GeoTrust. Network Solutions has support for 256-bit encryption, with more than 99% browser recognition, excellent round the clock support that includes online chat, fast issuance times and free reissues. What’s more, Network Solutions is a well-known and trusted brand.

Choosing the best and most reliable SSL certificates available might be a matter of trust.  You may be getting a provider that gives out inexpensive certificates but are not known.  At the same time, some of the more inexpensive certificates are just as reliable as the expensive ones. Beyond that, you should take a look at the level of service that your provider is giving you. They may be hyping it all up but just cannot give you competent and efficient customer service.  The certificate providers mentioned in this article are very well known and trusted, with packages that allow you to get the level of security you need at a price you could afford.

http://blog.pluralsight.com/top-reliable-ssl-certificates

Why is godaddy HTTPS/SSL certification so much cheaper than digicert, thawte, and verisign?

I am a novice on HTTPS/SSL but GoDaddy charges $12.99 and Digicert, thawte, and Verisign charge $100-1000+ for SSL certificates.

I must be missing something on the quality of the encryption or something. Can someone explain some of the basic differences that lead to these dramatically different prices?

Update $12.99 is a sale price. Typically SSL certificates cost $89.99 on GoDaddy. Here's a link on Godaddy which makes the very comparison this question asks about: http://www.godaddy.com/Compare/gdcompare_ssl.aspx?isc=sslqgo002c

Apart from unserious offerings, you can distinguish between cheaper domain-validated SSL certificates and the more expensive extended-validation SSL certificates (EV).

Both certificates are technically the same (the connection is encrypted), but domain-validated certificates are cheaper, because the seller only have to check the domain. The EV-certificates also require information about the owner of the domain, and the seller should check, if this information is correct (more administrative effort).

Normally you can see the difference when you visit the site with a browser. Firefox for example will highlight the domain in blue for domain-validated SSL, and green for extended-validation SSL.

Two examples:

https://accounts.google.com/ (domain-validated)
https://www.postfinance.ch/ (extended-validated)

In most cases the domain-validated certificate is fine, the user will have no disadvantages and the EV-certificates are really (too) expensive.

i just found that GoDaddy doesn't allow to "duplicates" certificate for your wildcards SSL.

That's a pitty since this is often used when you manage a farm of server and each one has its private key / csr.

(to compare, digicert do allow them, and unlimited number of them)

To be quite honest. there is absolutely NO difference when it comes to SSL certificates. The only contributing factor is the EV / non EV / Wildcard tags.

EV == Extended Validation: This means the site is actively " pinged " by the Certificate Authority on the provided IP of the domain, then a server-side script compares the IP address of the ping response from the CA, and the IP address YOU are visiting. This does NOT guarentee that there isn't a man-in-the-middle attack, or net-wide DNS poisoning. This just ensures that the site you are viewing is the same one the CA sees.

Non-EV == no one is actively checking the domain's IP against a logged / provided IP for security purposes.

Wildcard == *.domain.com based Certificates are often used when people have a multitude of subdomains, or a set of subdomains that are ever-changing, but still need valid SSL encryption.

The truth behind SSL Certificates.

You can make your own. They are no less secure than any other certificate. The difference being a " self-signed " certificate is not " vouched for " by any third party.

The problem with SSL Certificates is they are extremely over-priced for what they are. There is absolutely NO garentee that the site you are visiting belongs to whomever is listed on the certificate as owner / location etc. This defeats the purpose of the third-party-trust-chain model SSL was developed to use.

ALL Certificate Authorities known as CA's that sell their certificates, wants the user to believe that their certificate is somehow better. When in fact, they never check the information provided for the certificate unless there is an issue that may cost them revenue. This practice also defeats the purpose of the SSL trust-chain model.

I know of only ONE CA that indeed validates it's certificates. This is CACert.org.

For them to issue a " complete " certificate (business name, name, addres, phone etc..) you must meet one of their assurer's FACE-TO-FACE!.

However. most browsers do not use CACert.org due to pressures added to them by mega corporations like Thawte, Comodo, and Verisign.

So.. to sum it all up.

The only differences between certificates is the behavior of the CA. Certificates can't really be trusted to verify anything other than the connection to the site is useing encryption.

At the end of the day, people think paying $100 - $1000 somehow equates to trustworthiness. This is NOT the case. It just means you deal with less sophisticated or less established crooks.

Reference:
http://webmasters.stackexchange.com/questions/28595/why-is-godaddy-https-ssl-certification-so-much-cheaper-than-digicert-thawte-an

SSHGuard - Block SSH Brute Force Attacks

SSHGuard monitors logging activity and reacts to attacks by blocking their source IP addresses. sshguard has born for protecting SSH servers from the today's widespread brute force attacks, and evolved to an extensible log supervisor for blocking attacks to applications in real-time.

SSHGuard is given log messages in its standard input. By means of a parser, it decides whether an entry is normal activity or attack. After a number of attacks, the IP address is blocked with the firewall.

These are the available blocking backends:

• SSHGuard with PF (OpenBSD, FreeBSD, NetBSD, DragonFly BSD)
• SSHGuard with IP FILTER (FreeBSD, NetBSD, Solaris)
• SSHGuard with IPFW (FreeBSD, Mac OS X)
• SSHGuard with netfilter/iptables (Linux)
• SSHGuard with TCP wrappers / hosts.allow (almost any UNIX system)

1. SSHGuard installation

To install SSHGuard under FreeBSD, OpenBSD, enter:

Packet Filter support:

1	make install clean -C /usr/ports/security/sshguard-pf

IP FILTER support:

1	make install clean -C /usr/ports/security/sshguard-ipfilter

IPFW support:

1	make install clean -C /usr/ports/security/sshguard-ipfw

To install SSHGuard under Debian, Ubuntu (netfilter/iptables), enter:

1	sudo apt-get install sshgurad

To install SSHGuard under CentOS, Fedora, RHEL (netfilter/iptables), enter:

1	yum install sshgurad

2. SSHguard backend configuration

How To Set Up SSHGuard with OpenBSD's Packet Filter (PF)

The Packet Filter (PF) configuration needs a rule that blocks TCP traffic to the SSH port from addresses that proven source of attacks.

Edit the PF configuration file, usually /etc/pf.conf:

vi /etc/pf.conf

Add the line in the table section

1	table persist

and the following line in the packet filtering rules:

1	block in quick on $ext_if proto tcp from any to any port 22 label "ssh bruteforce"

Replace $ext_if with your WAN interface name if needed.

To reload the pf configuration, enter:

1	pfctl -f /etc/pf.conf

To display the set of addresses blocked in the SSHguard table at any time, enter:

1	pfctl -T show -t sshguard

How To Set Up SSHGuard with IP Filter

IPFilter is configured by a rules file, usually /etc/ipf.rules.

It is your role to rule locate a suitable position in which SSHGuard can include rules in this file. If you have a pass-all rule for sshguard, it must stay after this block. Then, insert this block where you want SSHGuard rules to be wrapped:

##sshguard-begin##
##sshguard-end##

SSHGuard will insert and withdraw rules within this block for blocking and releasing attacker addresses, then run ipf for reloading the chain.

You can get the set of addresses blocked by SSHGuard at any time by reading the ipf configuration file itself: they are listed inside the sshguard block delimiters.

How To Set Up SSHGuard with IPFW

SSHGuard adds blocking rules with IDs from 55000 to 55050 by default. If a pass rule appears before these, it is applied because IPFW runs a first-match-win policy.

If you have an allow policy higher than 55050 in your IPFW chain, move it to a lower priority.

To display the set of addresses blocked bySSHGuard at any time:

1	ipfw list | awk '{ if($1 >= 55000 && $1 <= 55050) print $5 }'

How To Set Up SSHGuard with netfilter/iptables

You have to create a new chain in which SSHGuard will append blocking rules:

# IPv4 support:
iptables -N sshguard
# IPv6 support:
ip6tables -N sshguard

Update the INPUT chain to also pass the traffic to the SSHGuard chain at the very end of its processing:

# block abusers for SSH , IPv4 and IPv6
iptables -A INPUT -p tcp --dport 22 -j sshguard
ip6tables -A INPUT -p tcp --dport 22 -j sshguard

Verify that you have NOT a default allow rule passing all ssh traffic higher in the chain. Verify that you have NOT a default deny rule blocking all ssh traffic in your firewall. In either case, you already have the skill to adjust your firewall setup.

NOTE: When rebooting, most systems reset the firewall configuration by default. To preserve your configuration, you usually use the iptables-save and iptables-restore utilities. However, each Linux distribution has its own "right way".

How To Set Up SSHGuard with TCP wrappers

TCP Wrappers decide when to accept or reject connections based on a user-provided file, typically /etc/hosts.allow. Through its "hosts" firewall back-end,SSHGuard can manipulate this file by dynamically adding and removing rules for addresses that are found abusing any service monitored.

This backend requires no configuration, just make sure to create the /etc/hosts.allow file if it does not exist.

When SSHGuard starts with the hosts back-end, it creates a special block in the hosts.allow file, enclosed in a ##sshguard## pair. When an address is blocked, SSHGuard puts inside this block a DENY rule, so that all libwrap-enabled programs will reject connections from that address.

While running, SSHGuard's block in /etc/hosts.allow will contain rules saying "Deny connections from this list of hosts, to ALL services"; these will look some like this:

##sshguard##
ALL : 10.1.2.3 11.5.4.3 : DENY
##sshguard##

Reference:

http://blog.up-link.ro/ssh-security-how-to-block-ssh-brute-force-attacks-with-sshguard/