Can web sites detect whether you are using private browsing mode? Most modern browsers support "private browsing mode" (also known in Chrome as "Incognito mode"), where the browser does not save any information to disk about your browsing while in this mode.
In modern browsers, can a web site detect whether a user who is visiting the web site has private browsing mode enabled or not?
The background research I've done.  Here's what I've been able to find related to this question.  Unfortunately, it doesn't really answer the question above.

A 2010 study of private browsing mode showed that it is possible for web sites to detect whether the browser is in private browsing mode, by using a CSS history sniffing attack.  (In private browsing mode, sites are not added to the history, so you can use history sniffing to check whether the visitor is in private browsing mode.)  Since then, though, modern browsers have incorporated defenses against CSS history sniffing attacks.
Consequently, I would not expect that method of detecting whether the browser is in private browsing mode to be successful any longer.  (I realize the defenses against history sniffing are not perfect, but they may be good enough for these purposes.)

There may be ways for a website you're visiting to learn whether you are currently logged into other sites (think: Facebook).  If the user is currently logged into other services (like Facebook), a website could plausibly guess that the user is not currently using private browsing mode  -- this is not a sure thing, but perhaps one could make some kind of probabilistic inference.  However, if the user isn't logged into other services, then I guess all we can say is that we don't know whether private browsing mode is in use.  It is possible this might yield a partial leak of information, I suppose, but it sounds unreliable at best -- if it even works.  It is also possible that this might not work at all.

So, can anyone provide any more recent information about whether there's a way for a website to test whether its visitors are using private browsing mode?

Note this answer was given in 2011. Today the answer is an unequivocal YES -- as of this writing in 2020 there are reliable techniques in wide use and have been for a while. Please see one of the good current answers below 1 2 for more up to date information.
I'm not sure you could reliably detect private browsing, but I think you may be able to apply some heuristics to make a good guess that a user is using various privacy-enhancing features. As indicated in my comment on the question, whether this is good enough or fits your application depends on what you want to be able to do in reaction to detecting private browsing. As Sonny Ordell mentioned, I'm also not sure that you can distinguish private browsing from the ad hoc use of various privace-enhancing features (e.g. manually clearing history or cookies).
Let's assume you operate a web application, and you want to detect when one of your users (with an account) switches to private browsing. I'm specifying that the user has an account, because this strategy relies on tracking various bits of behavior data. The aspects of private browsing are (at least in Firefox): history, form/search entries, passwords, downloads, cookies, cache, DOM storage. I'm not sure how to probe for downloads, but I think the others can be probed. If you get a positive detection on all of them, it seems more likely that your user is private browsing.

In the trivial case, you keep track of (IP, user-agent) for each user. When you get a cookie-less request for a matching (IP, UA) record, you might infer that the corresponding user is private browsing. This method fails (no detection) if:

He uses something like ProxySwitchy or TorButton to activate Tor during private browsing, thus changing IP.
He switches to a different browser (e.g. usually uses FF and switches to Chrome for Incognito mode).
The switch to private browsing is not immediate and his ISP has issued a new IP (e.g. on Friday he was 10.1.2.3, he didn't use your app over the weekend, and on Monday he is 10.1.4.5).

As mentioned in Sonny Ordell's answer, if another person uses the same browser in private browsing mode to access a separate account on your site, you will get a detection -- but this is a slightly different case than if the "normal" user simply switches to private browsing mode.
You'll get a false-positive if the user simply clears his cookies for your site, or uses a secondary profile (e.g. I keep a few different Firefox profiles with different sets of plugins for certain testing and/or to avoid tracking, though I'd guess this is very uncommon).

As a more complex check, you could use something like EFF's panopticlick and maintain a browser fingerprint (or collection of fingerprints) instead of just the UA for each user. This fails in situation 2 mentioned above (e.g. if the user exclusively uses FF for identifiable browsing and Chrome for incognito). The fingerprint will be much more generic (and thus much less useful) if the user has javascript disabled. The fingerprint will change if the user selectively enables javascript in different sessions (e.g. NoScript with temporarily allowed sites).

You may be able to defeat issue 1 (Tor) by detecting access via a Tor exit node, and combining this with fingerprinting. This seems like it would only be helpful in a narrow range of cases.

Instead of just cookies for the checks above, test localStorage. If it's typically enabled, and your key isn't in the storage for this visit, and the fingerprint matches, then this is probably private browsing. Obviously, if the user normally has storage disabled, then you can't use it. The failure modes are similar to those described above for cookies.

I haven't tested or developed the idea, but I suppose you could play games with Cache-Control. (A quick search reveals that this isn't an original idea -- that project has what looks like proof-of-concept code.) This strategy fails if the user goes through a shared caching proxy -- the meantime page mentions anonymizer.com. Firefox, at least, doesn't use the cache in private browsing mode. (See this site for a demo of cache-based tracking.) So you could combine this with the UA/fingerprinting mentioned above: if your cache tracker indicates this is a first visit, then you can guess that the user is private browsing. This fails with a false positive if the user cleans his cache; combine with other techniques to get a better guess.

You could detect and track, for each user, whether the browser autofills a certain form element. If you detect that a given user doesn't get autofill on that form element, you might infer private browsing. This is brittle -- perhaps the user is not using his "primary" computer, but you could combine it with fingerprinting as mentioned above for a more reliable guess.

Side-channel timing attack: detect and track the typical time it takes for each user to log into your app. There will be variations, but I'm guessing that you could get an accurate guess about whether someone is using password autofill. If a user normally uses password autofill (i.e. fast transition through the login page), and then for a given visit (with a matching fingerprint) is not using autofill, you can infer private browsing. Again this is brittle; combine with other techniques for a better guess. You'll also want to detect and correct for network latency on a given page load (e.g. perhaps the user's network is just slow on a given day, and a slow login page transition is just latency and not a lack of autofill). You can be slightly evil and auto-logout the user (give them a bogus error message, "please try again") to get a second data point if you're willing to annoy your users a bit.

Combine this with what you mentioned in the question about detecting if the user is logged in to other services (e.g. Facebook), and you can have more confidence in your guess.

If you're really motivated, you could play games with DNS and tracking page load times. A quick test of FF 3.6 and Chrome 15 seems to indicate that neither browser clears the DNS cache in private browsing mode. And the browser has absolutely no control over the local system's DNS cache. If you use a side-channel DNS timing attack to perform user tracking as an alternative (or in addition to) fingerprinting, you may get a more reliable guess. I'm not sure how reliable tracking via DNS timing will be.

Detection of "anonymous" users in private browsing mode will be much harder, since you haven't had the opportunity to accumulate data on their "typical" behavior. And, since most of the features only kick in when they end the browser session, you don't really know if they're ever going to be back.
With that said, here's an idea to detect private browsing by anonymous users, if you're willing to be evil, and you had some resource for which you knew a user was willing to give your site a second chance, and you can force the user to enable javascript. Track fingerprint, set a persistent cookie, localStorage, cache -- whatever you can do to track the user. If it's a first visit according to your fingerprint, crash/hang the browser via javascript (or flash, or whatever evil tricks you know). Suck up tons of memory, or get stuck in a loop, or whatever it takes so that the user closes the browser. Then when they return, you see (from the fingerprint) that it's a second visit. If the cookie/storage/cache/etc aren't set, then you can infer that the first session was private browsing, and I suppose you might infer that the second session is probably also private browsing. This obviously fails if the user doesn't come back, or if you can't crash / convince them to kill the browser window. As a bonus, if you send them to a custom URL, and they're in non-private-mode and restore the browsing session then you can guess they aren't in private browsing mode (unless they bookmarked the URL).
Everything above is full of holes -- plenty of room for false positives or negatives. You'll probably never know if I'm using private browsing, or if I'm running a browser in a VM with no persistent storage. (What's the difference?)
The worst part is probably that if you do get an answer with a reliable method for detecting private browsing is that it seems unlikely to remain viable for very long as browsers either "fix" it or users find workarounds to avoid detection.


tripwire report - inode number I am investigating Tripwire and have stumbled upon something about which I am unsure. In a tripwire report generated after I modified hosts.deny to include an extra #, I noticed the inode number changed from 6969 to 6915. I would like to know why this happened. I know inodes are records which store data about where data is stored on the file system, but would like to know why this number changed for a simple # being inserted.

This is a common method of editing files in Linux. Your editor opened the file, wrote your new changes someplace (with a new inode), and when that file was completely written it linked the hosts.deny location to the new inode.

The reason this is done is to prevent file locking issues and to avoid partially clobbering a file. In this way, if I remove a file that's open in a program, that program doesn't end up with garbage data. In fact, as long as an inode is referenced somewhere, it remains in-tact.


Are post requests secure? If a post request is sent from a client on a website without SSL, is the request secure?

For example, I visit a site badsecurity.com, and I login using a password:

Will this password be encrypted if there is no SSL? (I am pretty sure it is not, unless it's https/ssl or there's some other encryption added to the form?)
Is it possible for the post message to get intercepted somehow, say using a packet sniffer, and for the intruder to view the post request's text?

(I am not asking if post requests can be forged)

No. Not at all. They are sent in plaintext. Without SSL, a POST request is just as secure as a GET request. Sure, it may not show up in the URL, but it is not secure in any way.

  Will this password be encrypted if there is no SSL?

No, the password will not be encrypted. The only reason it doesn't show up when you are typing it in is just the browser obscuring it so that people nearby cannot see your password in plaintext on your screen. It can be easily revealed by inspecting the DOM or using some javascript like this: javascript:alert($('input[type="password"]').value) .

  Is it possible for the post message to get intercepted somehow, say using a packet sniffer, and for the intruder to view the post request's text?

This is absolutely possible, and very easy to do. A packet sniffer does exactly this, and can view POSTed usernames and passwords in plaintext. To someone sniffing HTTP requests, a POST request looks pretty much identical to a GET request, except a POST request has "POST" at the top instead of "GET."

You didn't ask, but yes, post requests can be forged as well.


Which attacks are prevented by switching the user within the docker container, given a read-only root fs? There are recommendations to run processes as a non-privileged user within the docker container:

[...] run your processes as non-privileged users inside the container

See: docs.docker.com, also 1, 2
One reason I can see is that an attacker who got access to the container can install malicous software. However, I run my container with read-only root file systems. So this does not make a difference to me.
Given that I use a read-only root file system, is there any other reason why using a non-root user inside the container would make sense?
To clarify: I am NOT asking about running the docker deamon/starting the container as a non-root user.

So running a non-root user inside the container (assuming you're not using user namespaces) could still be helpful. There have been some container security issues that required the container to run as root to be effective.
For example abstract shimmer needed to be uid 0 and have host networking to be effective.
Also the runc security issue from 2019 CVE-2019-5736 required the container being exploited to run as root, for the issue to be exploited.
The problem is that, even though docker (and other linux container runtimes) apply restrictions to the running process, being uid 0 can allow for security issues to occur.
Running read-only filesystems is another useful security mechanism and whilst it might make attackers lives harder, it doesn't cover exactly the same ground as using a non-root user inside the container. For example if an attacker can add their exploit to running memory without touching disk, then read only filesystems won't help.
Typically I'd recommend both of these as complementary hardening steps for containers. The other option (instead of using a non-root user inside containers) is using user namespaces, or run the entire docker daemon as a non-root user, which is now a supported option.


Emails with links offering job I am a designer. I have received several emails offering jobs. There is a link. I never click to links in emails. I look at the sender address and look at google to see if it could exist a real firm with that name. Most of the time I see no company. So, I assume they are malicious emails.
Is that the way to deal with this? Is there anything else I could do to protect myself without losing opportunities?

Normally when you dont know the source of the link, my recommendation is to use a third party service (that checks domain and uri reputation) and use it in order to get information about that link. There is online services that gives you that service. If you can not get information of the URL just basically dont click and drop the email, if a real company wants to send you a reasonable work offer they will use a proper email with valid information.
You can use the google report one http://google.com/safebrowsing/diagnostic?site="my url to analyze"


Is using HTTP for OCSP a potential vulnerability? While inspecting my CA-approved cert, I noticed the following oddities:

Extensions/CRL Distribution Points:

  Not Critical
  URI: http://crl2.alphassl.com/gs/gsalphasha2g2.crl

Extensions/Authority Information Access:

Not Critical
CA Issuers: URI: http://secure2.alphassl.com/cacert/gsalphasha2g2r1.crt
OCSP: URI: http://ocsp2.globalsign.com/gsalphasha2g2

Shouldn't the OCSP information be published via HTTPS (i.e., protected with TLS), to protect against MITM?  Is that field just noise that shouldn't be used by a client?

I know that Is publishing CRLs over HTTP a potential vulnerability? explains that CRLs are always signed, so it is not a vulnerability to publish CRLs over HTTP.  What about OCSP?

(Somewhat related to Does any technology prevent a CA unilaterally revoking a certificate?)

The CRL's and also the OCSP responses are signed by the CA. This means any kind of manipulation will already be detected even if the CRL or OCSP response is transferred using an insecure transport. Thus the protection against tampering which is offered by https is not needed.


RFID – based identification card I have the question below, I did question 1 and 2. I am failing to understand question 3.

You have been asked to participate in developing the requirements for RFID-based identification card for students, faculty and affiliates at a university.

First, list five to ten different uses of the card.
Second, from that list of uses, detail what data the card needs to broadcast to receivers that will accomplish those uses.
Third, identify uses that could be made of that data by rogue receivers surreptitiously planted around the university campus. Which rogue accesses threaten personal privacy? In what ways? What is the degree of harm?

My solution so far is as follows:

RFID-based identification card can be used:

To check in and out of the university gates.
Data needed by the card to accomplish this usage is: student name, student number and student photo.
To track attendance and prevent unauthorized entry.
Data needed by the card to accomplish this usage is: student name, student number, lesson name, date and time.
To borrow books at the library.
Data needed by the card to accomplish this usage is: student name, student number.
To buy food at cafeterias.
Data needed by the card to accomplish this usage is: student name, student number, amount available.
To sign in and out of the university photocopying machines.
Data needed by the card to accomplish this usage is: student username and password.

Please help with the following: Third, identify uses that could be made of that data by rogue receivers surreptitiously planted around the university campus. Which rogue accesses threaten personal privacy? In what ways? What is the degree of harm?

If someone puts a rogue receivers at the library, according your scheme he would get the student name and number. All this seems public or near-public information.

On the other side, still following your scheme, the same rogue receiver put near the photocopying machine will record the student logins and passwords, allowing an attacker to impersonate them on the network and, among other things, access their data. A far worse situation.

Putting the same receiver in the cafeteria would record student name, number and remaining amount. Sure, it would be a personal information leakage, there might be gossips about how much one has on his card compared to another, but there should be no real threat since the information regarding the remaining amount may not be usable somewhere else, as opposed to the credentials seen previously.

As you can see, these situations lead to very different consequences. The goal of the exercise seems to be to let you sense that: according to your scheme which data would be recorded, is this data secret / personal, and does it present an supplementary threat over the simple information leakage.


Are image uploads also vulnerable to sql injection? I have some good knowledge how sql injections work. I see that the Googling inurl upload.php will tell one about the upload paths in a website. My Question is that if a person finds a path by which he can upload images only, can he still perfrom sql injections? Please guide.

Actually they can be malicious. One of the challenges of the CTF of 29C3 was actually to upload an image and perform SQLi with it.

How did it work? Well images have metadata, after you uploaded the image, the metadata was extracted and put into the database. So the trick to get the flag was to include SQL in the metadata. (the input was not correctly sanitized).


Why is breach-detection site "Have I Been Pwned" considered safe? Whether it be due to technology the site is using, or any manual behind-the-scenes work with the data, why does this breach detection site seem to be unquestioningly safe?

Wouldn't the data of you, as a user(breached/pwned or not), utilizing this tool be used against you if not secure properly(see examples below)? What is this website/project doing or using to prevent this?

If you go to this site, enter your information, you are at least providing the potential Boolean checkbox of: "Visitor [YourUsernameProvided] cares to check."

Is this not valuable data? If black hats out there have something like a list of 2,000,000, and they take/intercept the data provided by this site, couldn't they get a smaller list of 12,000? A curated list of targets that "care"?
"Targets that care" can mean "Targets that have value". It can mean "Targets that are active". Perhaps even "Targets who are actually humans, not bots".

On another note, if you use the site to check multiples of your usernames, wouldn't you potentially be crafting a list of "All these usernames have been accessed from this location" and therefore be tying all your online personas together?

This all sounds like free work given to black hats.
So, what technologies or methods are in place to prevent such a thing?

This article by the service's creator may answer some of your questions.

https://www.troyhunt.com/here-are-all-the-reasons-i-dont-make-passwords-available-via-have-i-been-pwned/

Specific details that might be of interest:

Passwords are not stored along with user details because there is no such thing as "secure enough" storage for this kind of thing
Have I Been Pwned? won't tell people their own passwords anyway, even if the account ownership could be verified
Some more sensitive breaches - Ashley Madison being the first such breach - are kept more discrete by only disclosing that an email is in the breach corpus after confirming you control the address

Here's an additional article covering the Pwned Passwords feature:

https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity

Of note, Pwned Passwords as the downloadable list provides only Hashed Passwords. There is some question as to whether this constitutes a password dictionary that can be exploited, but given it doesn't associate the passwords at all with who used them or where - reversing them to use them just wouldn't be that valuable. And while some may not consider this a satisfactory answer... these passwords are already out there.

The most recent "Collection #1" breach, with over 12,000 sources is evidence enough that Have I Been Pwned is not the only one aggregating this type of information. And the competition does not have your best interest at heart.

Pwned Passwords as a lookup service uses k-anonymity to provide some safety. It works basically like this:

You hash the password with the same algorithm Pwned Passwords uses (SHA1)
Submit just the first 5 characters for the hash, which given the sample size of the database will return many results for any given 5-character combo
You search the returned list to see if any of the results match your hash from the first step

I can't see the future, so I don't know if this collection of information will ever become exploitable in any meaningful way... but as far as I can tell, Have I Been Pwned is provided as a useful service provided for virtually no gain, in the interest of public safety.


What is proxyjudge.info? I have setup a nginx server literally an hour ago. It is open to the world but is not in production. There is no CNAME or other DNS records associated with the server's IP address yet.

In the acceess.log I see the following:

163.172.7.162 - - [18/Jan/2017:00:51:23 +0000] "GET http://proxyjudge.info/ HTTP/1.1" 400 270 "-" "Mozilla/5.0 (Win
dows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 (.NET CLR 3.5.30729)"
163.172.7.162 - - [18/Jan/2017:00:51:48 +0000] "\x04\x01\x00P\xC62\x83\x9C0\x00" 400 172 "-" "-"
163.172.7.162 - - [18/Jan/2017:00:51:48 +0000] "\x04\x01\x00P\xC62\x83\x9C0\x00" 400 172 "-" "-"
163.172.7.162 - - [18/Jan/2017:00:51:48 +0000] "\x05\x01\x00" 400 172 "-" "-"

I have a couple of questions:

What is the purpose of proxyjudge.info's probing of my server? I took a look at their web site  but I cannot figure out their intention. I think I would like to find out if it is malicious or not.
After first hit it sent several request to the url like \x05\x01\x00. What can be discovered from this request?

I fail to find any substantial information via google search. Based ion http://mxtoolbox.com/ the source IP is not blacklisted. The bigger issue for me is that I don't I know how to judge if a certain traffic to my server is risky or not.

It is testing if your server is configured as HTTP proxy.
If you open the proxyjudge.info website, they also tell you this.

Since your server returns Error 400 to the request, everything seems to be fine.


Is Redux a secure place to store JWT tokens? I've been teaching myself Redux, wondering how secure it is to store JWT tokens in a state of Redux.

For example, here is a reducer which is responsible for setting and resetting a token.

export default function loginReducer(state = {
    token: "",
}, action) {
switch (action.type) {
    case "SET_TOKEN":
        {
            return {
                ...state,
                token: action.data,
            }
            break;
        }
    //other cases here
    return state
}

Then, you can store a token in the following way.

handleSubmit(values) {
    //Calling an API
    }).then((response) => {
        response.json().then((jsonReponse) => {
         //This is where the token is stored!
         this.props.dispatch(loginAction.setToken(jsonReponse.token));
        });
    });
}

The main purpose of using Redux is to organise states in one place, so I thought it would be reasonable to maintain tokens there.

However, I haven't found a good information resource which explains how secure/vulnerable it is to do so.

(I found several posts as to localStorage vs Cookies.
Apparently Cookies would be a secure place for storing tokens, as far as I've researched)

Any advice will be appreciated!

Redux stores the state in JavaScript object. This makes it vulnerable to an XSS attack just like localStorage or sessionStorage. If you need your JWT be readable on the client side you can freely use Redux, just be sure you take care of XSS properly. If the JWT is not required on the client side, better leave it in httpOnly cookie and handle CSRF instead.


What's the actual danger of public key spoofing? I am reading an excellent beginner's cryptography tutorial, and on this page there is the following blurb:

  Public-key cryptosystems have one significant challenge − the user needs to trust that the public key that he is using in communications with a person really is the public key of that person and has not been spoofed by a malicious third party.

I'm not immediately/inherently understanding this. If private keys cannot be feasibly derived from public keys, who cares if I have a spoofed public key? All that means is that someone handed me a bad public key, and the receiver won't be able to decrypt it. Or is that the attack?!?

It's an attack, FOR SURE And that's why : all the crypto-systems have JUST ONE common problem, regardless of their other differences, : a key distribution problem. Yjat's why it's essential to buy a holographically-protected licensed CD with Windows and so forth : it contains a correct and true public key. If a malicious third party will ship you a software with public key changed - it will easily wiretap your traffic and - maybe - even make a MitM with a correct key, so the software vendor will likely see no difference.


Do I run the risk of not being anonymous with this setup? Basically, I created a gmail account using a VPN, and then created a tumblr associated with that Gmail also using a VPN. However, I am now realizing that tumblr records the type of device I am using and google tracks everything so my browser fingerprint could give me away.

I want to know, if I delete the email and the tumblr that I created using a VPN, then install a VM on my laptop, use a VPN on the VM, install Tails and Tor, and then recreate the GMail and Tumblr, how anonymous would I be?

Would google then still be able to use a browser fingerprint? Or would tumblr still be able to identify what kind of device is being used?

And I also have a VM right now, should I uninstall it and then reinstall it to start fresh so that no previous information could be used. When I last used my VM I didn't have a VPN on

Browser fingerprints always work. You can make them much less effective by disabling Javascript etc, but you can't keep a server from fingerprinting the browser (and the device and operating system) based on the HTTP headers that get sent to the server.

The point of using Tails would be that everybody who uses it shares the same browser fingerprint, so it can't be used to uniquely identify you. But running Tails will make you stand out as a Tails user.

Running Tails inside a VM adds a layer of security in case your instance of Tails is hacked (possibly through a browser weakness) - so it will keep the files you store on the hard drive of your computer/laptop out of reach of an attacker, but it won't make a difference if you're just interested in not providing information about your device to a server (eg GMail).

https://panopticlick.eff.org/ has a nice service to measure how unique you are based on your setup.


How to exploit escapable JSON parameters I have an HTML page with this bit of code in it:

    <login-page params="{&quot;redacted&quot;:&quot;redacted&quot;}"></login-page>

So where it says redacted, there are a lot of parameters, and one of them is modifiable using a URL parameter, meaning I can change this parameter in the URL to abc and it will put abc into those JSON brackets. Using this, I found that it does not properly filter braces, meaning that in this parameter I can put braces that are parsed as a new JSON area within the braces already there.

It's hard to explain but for example, I can make the URL parameter "{test}", and those above parameters will look like the following (assuming one of the redacted areas was the URL parameter's output:

{&quot;redacted&quot;:&quot;{test}&quot;}

It seems that being able to put my own JSON brackets in here should allow me to run my own JSON code, but is this possible, and is there any risk associated with the fact that they don't filter braces at all?

Thanks

I am going to ignore everything cept:

  and is there any risk associated with the fact that they don't filter braces at all

In a word No.

What you are looking at is all Client Side HTML/JS and while I could see how you would believe modifying it would be a security flaw ... It isnt really, because it only effects you and your computer.

For example if you press F12 in your browser and type the following into the console:

y = document.getElementsByClassName('gravatar-wrapper-32');
for (idx = 0, len = y.length; idx < len; ++idx) {
  y[idx].firstChild.src = "https://www.gravatar.com/avatar/370bb2bee74fc88763dc0fe35477e24c?s=32&d=identicon&r=PG"
}

All of the gravatar images on the page will be changed to mine ... and this is how you hack the gibson ... just kidding

But if you bring up the same page in another tab you will notice that this change has only effected the first tab ... thus it will not effect anyone else on the site.

The same is true for your login-page params ... if you wanted to you could just change the entire string on client side and ... no one would really care.  when you submit the JSON is the real test.

If the developer of the Server Side code does not properly validate the JSON to make sure extra things where not added or removed THEN there would be risks associated (but that is a topic for another question).


How can I determine the vulnerability for a sub domain takeover attack? I have found research efforts on explaining how sub domain takeovers can take place authored by a gentleman named "Patrik Hudák". Through his site's blogs he illustrates and conveys an understanding of the phenomenon:

https://0xpatrik.com/subdomain-takeover/

He has also crafted a Master's thesis on the subject matter:

https://is.muni.cz/th/byrdn/Thesis.pdf

I would like to find specific fields of interest using some advised tools such as dig, whois and curl to distinguish if a subdomain is vulnerable or not.

I actually know Patrik personally and will definitely ping him concerning your request.

I have published numerous technical write-ups on subdomain takeovers that include identifying vulnerable hosts using common commands and libraries that may be of interest to you. The best starting point is probably "A guide to subdomain takeovers".

Setup and workflow

If you want a really basic setup, I would advise to use a combination of a subdomain enumeration tool to retrieve a list of subdomains for your target, meg for sending requests and storing the responses in a local folder, and then grepping for fingerprints listed in "Can I takeover XYZ?" (most subdomain takeover related tools rely on this project for identifying vulnerable hosts) in the folder where meg stored the responses.

A basic workflow using the tools listed above would look roughly as follows.

1) Enumerate subdomains using a tool such as subfinder (the process that these tools use is described in detail in the HackerOne write-up linked above);

$ subfinder -d example.com -o output-tmp.txt

2) Ensure that all hosts are prefixed with http:// so that they can be run through meg. You could also use httprobe, which is a slower process but might yield better results;

$ sed 's#^#http://#g' output-tmp.txt > output.txt

3) Run meg to fetch the index pages of all the enumerated subdomains;

$ meg -L -c 200 / output.txt responses

4) Grep through the responses for fingerprints associated with vulnerable subdomains.

$ grep -Hnri "There isn't a Github Pages site here." responses

Practice

In my opinion, the simplest way to learn about subdomain takeovers is to point a subdomain of yours to GitHub pages and to follow the steps above to claim it. This should give you a feel for the entire workflow and possibly give you a better idea of the security implications.

Further reading

"DNS hijacking using cloud providers – No verification needed" by Frans Rosén covers a lot of the steps described in the previous section. He also goes into detail about how he identifies vulnerable subdomains and lists a couple of tricks to make your workflow more efficient.


What use does a BIOS/EFI password have? I have become quite a password-obsessed individual. I password-protect my HDDs, my files, and now even the BIOS/EFI on the various systems I own.

But I have discovered that if you forget your BIOS password, it is easy (enough) to simply reset it/disable it via physical access to the insides of the machine, or in some cases like the EFI of modern Apple hardware, Apple can even override it via some 'master key' overriding code if they want to, without even needing to reset it at the physical hardware level (which is pretty disturbing).

So, with this in mind, what use is a BIOS/EFI password then?

What threat model is it effective against, and are additional measures (like storing the laptop in a safe/locking the desktop case with a key/padlock/combination lock, and maybe some robust 'intrusion detection' notification or logging system) recommended to make this extra password more worthwhile every time you restart your computer?

Is it a little bit like the lock on the front door of the house, still having its place even though the glass window right next to it can be smashed by a determined burglar who wants to get in anyway?

A BIOS/EFI password can only be considered effective because of security by obscurity. An attacker can easily override the BIOS password with only keyboard and power button access with something like this, or via physical access to the internals of the PC.

What use is it, then? Well, it makes you feel secure, but it really only deters people who don't know how to bypass it, though all you really need is a key generator, and that's even open source. I mean, built-in backdoors with open-source key generators can't possibly be secure. It's only because it's not common knowledge that it still exists.

So it's not as much of a deterrent as a lock on the front door of a house, maybe more of a sign that says "beware of dog," since it doesn't really take much effort to bypass on most systems, but just like the sign, the thought of a cute poodle won't deter anyone who goes to the effort of trying to break in.

If you're already encrypting your hard drive and again your files, then that's about as secure as you can reasonably get. Even if there was no way to easily circumvent BIOS passwords, an attacker could easily swap hard drives to gain access to data, assuming they had physical access.


In Visual Studio, what are the risks of simply opening an untrusted project? What are the mitigations? I'm looking at the source code of some potentially hostile code.  As usual, VS 2012 is giving me the security warning:  "You should only open projects from a trustworthy source" ... "ask me for every project in this solution"

If I press OK, without compiling and running the code, what could be done to my machine?
What should I inspect with a text editor before opening the project in VS?
What should I inspect prior to compiling the code?

Assume I have a [misguided?] intent to download and compile hostile code on a trusted network, and then move that compiled output to an isolated location?

This has to do with the project itself and the automation in Visual Studio.  It could potentially do quite a lot since Visual Studio can do some pretty low level stuff.  The way to mitigate it is to either check the project and solution files manually for build steps and such prior to opening (it's all human readable XML if you have much familiarity with Visual Studio and they aren't  generally too too long) or to simply add the source to a newly created project and solution.


What would the cryptographic impact be of knowing the output of /dev/urandom? Another noob question, I know, but something I'm unsure about.

If I somehow magically knew the output of /dev/urandom at any given time, how much would that weaken a given encryption system? Or, perhaps, what kinds of encryption schemes would be most harmed by reducing this randomness?

If you knew the output of /dev/urandom at all times and various keys were generated using /dev/urandom (say SSH/GPG private keys or an SSL certificates), you could in principle quickly (as in much quicker than brute-force) recreate a keypair by attempting using various states of /dev/urandom.  This would effectively bypass all the security methods in place (file encryption; https; data integrity protections) that are based on those now broken keys (this attack is exactly identical to obtaining someone's private keys/certificates).

There are various other things that rely on /dev/urandom that could also break.  For example, you could complete a TCP handshake from a IP address you do not control to a server with a cracked /dev/urandom as you could send a SYN, and then send an ACK and guess the server's sequence number.

Granted unless you have compromised a system to replace /dev/urandom with something else (or recorded the bits of /dev/random prior to using them), urandom is not entirely deterministic.  /dev/urandom will default to using entropy collected from various hardware components and only fall back to a pseudo-random generator when more entropy is needed than has been collected.


Can USB host ports be dangerous in uncontrolled environments? Virus etc? (Note: I was told this post belongs here rather than in Android Enthusiasts)

We have an Android device with 2 external USB host ports. Now I wonder what harm can be accomplished by an attacker with malicious intentions, provided that:

The user can not access settings or any App that we do not control
(i'd love an example of apps we would need to prevent access to)
USB debugging is turned off
Our device is rooted (just to mention)

Could you give me an example what harm an attacker could do, considered the above conditions.

As I understand it, if a USB is mounted, then for something to be dangerous, it has to be executed. However execution must come from "the inside", no? If we control the inside, then there shouldn't be a problem, right?

Consider this:
It is not possible for a USB-hosting device do determine what kind of USB-device the plugged in USB-device really is.

You plug in a USB-stick, the USB-stick tells the hosting-device: "Hey! Im a Keyboard!" and the hosting-device has no possibility to proof whether it really is a Keyboard.

So if you have the basic USB-features enabled (automatical mounting e.g. -> "PlugAndPlay"), there are a lot of possible attack-vectors.

e.g. your fake-keyboard or mouse or whatever can change all the 'settings' bye calling a scripted fake-user input.


Can someone eavesdrop on my home network? My network setup is:

First router+modem connected to ADSL cable
Second router is connected via LAN to WAN to the first router
My computer is connected to the second router via ethernet cable.
there is no configuration on the first router i just connected the second router with ethernet cable to the first router.

My question is if someone has access to the network of the first router+modem can he eavesdrop on my computer's communications?

And if the answer is "yes", is there something I can do when I believe that the first router that is connected to the internet has very poor security, especially against man in the middle attacks?

The first router is from my ISP and is very cheap, without many options in the web panel.  I can't replace it because my home telephone is connected to it.

the Wifi in the second router are disable i connected only via ethernet cable.

I assume that the wifi you are connected to is an access point hosted on the second router.

If your second router is running a properly configured firewall, the answer is "no"; an attacker who breaches your ISP-provided first router will not have direct connectivity to your computer.  He would be in a position to eavesdrop on any unencrypted connections going from your computers to the Internet (HTTP is not safe, but HTTPS is.)

As far as your WiFi security goes, be sure you are using WPA2, and don't use a trivially easy-to-guess password (don't use your names, etc.) Instead of a password full of hard to remember symbols, try a silly two or three word combo, like "CloudRapidOlive"


3rd party API access: Is OAuth really required? Having a web application with a REST API (say, our-app.com), we want to open our API to 3rd party web applications (say, their-app.com). After some research, having read about OAuth, OpenID Connect, etc., I doubt if these are really required for our intended use. I think that the simpler implementation described below might do the job as well, extending our existing session-based login mechanism.

More exactly, we want to achieve the following:

The user has an account for our web application our-app.com, and is logged in.
The user visits their-app.com (in the same browser).
The user agrees to share her/his data with their-app.com.
Now, their-app.com can make authenticated cross-origin AJAX API requests to our-app.com. Since the browser sends the existing session cookie, no separate login is required if the user is already logged in on our site.

Can you please review my suggested implementation, and point our security flaws or other disadvantages? What benefits would we get from using e.g. OAuth instead?

Their-app.com registers for using our API. As a result, "their-app.com" is added as an allowed CORS origin to our database.
A user visits their-app.com in her/his browser.
TheirApp requests https://our-app.com/me to find out is the user is logged in.

Technically, this is a "withCredentials" AJAX request.
Since their-app.com is a registered origin, this cross-origin API call is allowed by our web servers. (All CORS requests from an unknown origin another-app.com would be rejected.)
If the user is not logged in, or if the user is logged in but did not yet grant access to their-app.com, the response will include a URL. This URL points to our login page (say, https://our-app.com/login?origin=their-app.com). TheirApp should then open this link in a new tab, to allow the user to login.
The login page will ask for username/password (if not yet logged in), resulting in a session cookie being set, and then ask something like "Do you want to allow their-app.com to access your data?"
Since all this happens in a separate tab, the password is safe from being observed by their-app.
If the user grants access, an entry ("their-app.com", userID) is added to the database, to remember her/his decision.

All cross-origin requests to our API are handled this way:

First look up if the origin is registered. If not, reject.
Then look up the user's session if a session cookie was provided.
If a user is logged in, but did not yet grant access to the origin, we reject the request, returning a link as described above.
If a user is logged in, and has already granted access to the 3rd party, then we process the request in the same way as same-origin requests from our own web app.
If not logged in, only public data can be accessed.

It all comes down to the old adage: "Good IT security is hard".

While none of the concerns are known by us here to be fatal (we can't know your whole business and client model), they do raise serious doubts or at least things to really think hard about, and are worth taking soberly.

Flip it round and look at your users' perspective. You are asking your users/customers to invest their time/money/resources in learning and leveraging your API (use-case: one supplier) vs. a standardised well-known API (use-case: many). If you cease activity their effort is wasted. If they want to reuse their own work they cannot as easily transfer or reapply it without additional and perhaps prohibitive work which they can avoid by not adopting that path at the start. There's a reason open standards are open - they may not suit everyone, but they have other advantages in the wider picture.
They will also be concerned how certain they are of this concept's long-term benefit to them as users. They may consider and evaluate the durability of your business, your approach, your commitment to this path, and their commitment to your commitment to this path, and they will at some level evaluate how certain they are that you and the product and their use of the product will all still be around in years to come (many aren't). What about interoperability? Perhaps it will be a concern whether their other suppliers care to include some lesser and proprietary API or a well-known one they can sell as a feature to other users of theirs, or whether data can be got out into other packages without having to write "shims" for each one. Will they want the maintenance burden or doubts this might raise?
Third, even if people might be keen for it, consider this too: what basis do you have for believing your approach would be more securely implemented than existing versions? That's not the same as "more securely designed". A home-made setup might be far better adapted and suited for your needs but are you confident you have the competence and skills to both design, and develop an implementation of that design, that will stand up to the real world of ITSec? Even if you think you can, would third parties whose trust you seek to use it, agree with you completely?
Fourth, consider that a framework that has its own developer focus, may respond more quickly and dependably to changes in the security world affecting it, or on the positive side, emerging new standards/developments. Do you have the resources in your business to commit to maintain a focus on keeping it up to date continually, once produced? (You might, you haven't described the business). Plan for a bigger resource drain than expected.

Your question wording is telling, and should be the final piece you need:

  I >>doubt if these are really required<< for our intended use. I think that the >>simpler implementation ... might do the job as well<<

In other words you seem unconvinced yourself that there is any real downside except that they may have extra features and competencies you don't need. But even so it might still be worth using the package even if you don't need all it has, because of its other many advantages of doing so. After all, few people use "most" features of any major software (the humble MS Word through to Apache web servers being quick examples) and yet the software is used, just not all features.

As a business, your aim is likely to be based on confidence (yours+clients), speed and cost/time efficiency. For most businesses considering a security need, a ready-made solution might routinely beat home-made proprietary hands down on all major fronts, even if it is more than they need today.


Reverse shell breaking instantly after connection has been established currently I'm preparing for OSCP and right know I'm working on reverse shells. Using msfconsole it's not problem to get a meterpreter-session, however meterpreter is not allowed during the exam so I want to go the "manual" way.

With msfvenom I create a payload for my victim windows 7 machine, I open a netcat listener on the correct port, download and execute the malicous exe file from the victim machine, and a connection will be established. But, when I type a command, the connection closes. In the screenshot you see what I'm talking about:

What am I doing wrong? As I said, using the exact same msfvenom command (just with windows/meterpreter/reverse_tcp instead of windows/shell/reverse_tcp) and msfconsole's multihandler everything works fine. So problems with the clients port (firewall rules for example) can be eliminated. Maybe I use a wrong payload...?

TLDR: to catch it with a netcat listener you need to use windows/shell_reverse_tcp, not windows/shell/reverse_tcp. Otherwise you need to use the multihandler.

Take a look at these two payloads from msfvenom:

payload/windows/shell/reverse_tcp
Windows Command Shell, Reverse TCP Stager
Spawn a piped command shell (staged). Connect back to the attacker
Total size: 283

Versus

payload/windows/shell_reverse_tcp
Windows Command Shell, Reverse TCP Inline
Connect back to attacker and spawn a command shell
Total size: 324

Notice how the first one is smaller, but it also says that it is staged. This means that it can be smaller because rather than cram all the necessary code into the payload itself, it just contains the bare minimum needed to connect back to a compatible listener and receive the rest of the code. This is done by msfconsole's multihandler, but not by netcat.

If you don't want to bother with spinning up a multihandler, you can use the stageless version, though it is slightly larger. Just make sure to pay attention when listing payloads to whether or not something is described as staged. You could also just filter staged payloads out of your initial listing: eg msfvenom --list-payloads | grep -v stage[rd]


Is there a good reason to turn off phpinfo()? New server setup and the server admin decided phpinfo was too scary. I guess the fear is that a hacker could somehow get phpinfo() to run from injected php and find out all the extensions that are installed, their versions, etc. But, as a developer, it's nice to know all the extensions and their versions, etc.  Is phpinfo a real threat? Or is this just an overzealous precaution?

In the past there have been exploitations which utilise the phpinfo() page, using some server globals it var_dump()'s when outputting variable info.

This information merely adds to what webtoe has to say, but it's yet another attack surface you should be weary of when you consider if your users really need phpinfo() access.

LFI WITH PHPINFO() ASSISTANCE


Does SOC1/SOC2 mandate installing non Security related patches I am looking at our patch management control for SQL Server databases and until now the process only requires us to install security patches.  Microsoft releases cumulative updates every month and it has got fixes for bugs and we have not installed these CU's unless we have hit a bug address in the CU or we think a bug fix for performance issue might help us.
During the last audit, the auditors asked us why we haven't installed the CU's.
Now my question is, does anything in SOC tell us to install anything other than security fixes? CU's contain bugfixes/improvements etc and I am not sure if SOC 1 or 2 defines those or the auditors were mistaken.  Isn't it similar to asking us why we haven't installed the latest version of SQL Server?

Your question does not say that the assessors are requiring non-security patches, they are just asking why you have not installed the CUs.
For Security, CU's include security updates. If I was assessing you, I'd ask the same question. How can you be sure, and how do you assure, that when you install individual security patches that you have patched everything that a CU does?
For Availability and Processing Integrity, non-security bug fixes are also important for maintaining that the system will meet contractual agreements. If there is a bug and you're not fixing it, then you risk your stakeholder's expected function of the system. Again, it's not about the CU but about applying the available fixes to ensure consistent and available operation.

CC8.1 Change Management:
The entity authorizes, designs, develops or acquires, configures,
documents, tests, approves, and implements changes to infrastructure,
data, software, and procedures to meet its objectives.
...
Identifies Changes in Infrastructure, Data, Software, and Procedures Required to Remediate Incidents — Changes in infrastructure, data,
software, and procedures required to remediate incidents to continue
to meet objectives are identified and the change process is initiated
upon identification.
...
PI1.3 The entity implements policies and procedures over system
processing to result in products, services, and reporting to meet the
entity’s objectives.
Detects and Corrects Production Errors — Errors in the production
process are detected and corrected in a timely manner.

source
This doesn't mean that you must apply all possible patches, whether security-related or not, but that you should have a process in place to 1) know that a patch exists, and 2) evaluate whether you need to apply the patch to meet business objectives.
So, the question: "why don't you install these patches?" is valid and expected and you should have an answer. It is ultimately up to you, your business case, and your contracts to determine whether the patch is applied.
My experience: I was the security architect who led an SaaS through their first SOC 2 Type 2.


Hardware USB Key to Reset Any Windows Password This tool requires physical access of course, and there are many things you can do once you have physical access, but this peaked my curiosity.

The tool in question: https://www.kickstarter.com/projects/jontylovell/password-reset-key?ref=discovery

Obviously the magic to this piece of hardware is what's contained on it, and if that is true, any usb key could be used to accomplish the same job. I know there are software like Katana and the like that can do similar things.

My question is, does anyone know what this could be running to make this happen? Is it rubber ducky-like (http://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe) or something else?

I'm a security professional and penetration tester by trade, but no administrative windows expert and most of my work is done remotely, so I put this out to the on-site guys and the windows experts.

I'm not looking to knock off the product, in fact, I think quite the opposite, its a cool piece of kit and may purchase one for kicks. Just curious if anyone knows whats going on behind the curtain.

The kickstarter page actually gives away the method:

  Using the key you can boot the PC into a special admin mode that allows you to view all of the user accounts and reset any password. Quickly regain control of the PC and get back to work.

Basically you reboot the PC with a custom OS located on the USB flash drive itself; from that OS, the relevant files on the disk are modified. The USB device is nothing special: it is just a normal USB flash drive; the "added value" of this device is purely aesthetic. Downloadable boot images which can do the same thing from a "normal" USB flash drive can be obtained from various places, e.g. this one.

This password reset method will fail if any of the following holds:

The boot-on-USB option was deactivated in the BIOS, and a BIOS password was set to prevent reactivation (of course, some BIOS accept "default passwords", and a BIOS password can be cleared by removing the CMOS battery, which is doable with physical access and a screwdriver).
The operating system uses disk encryption and requires a password upon boot -- not just as a verification, but because the encryption key is derived from the password (TrueCrypt can do that).

Also, as @Ben explains, a password reset is not recovery: that which was encrypted with a key derived from the old password remains inaccessible.


Security Audit - How to make sure a specific android app does not send my data to its data center We need to pass a specific security audit in our company. All our front line workers use the mobile phone provided by our company (controlled by Intunes) and they require to install apps such as CamScanner to capture some document.

So far only the apps developed by the company were installed on the devices. When installing CamScanner it asks for storage permission, which seems to fail the security audit.

Is there a way for us to prove that this specific software does not randomly access device storage (while the app is running in the background / not active) and send the data to their data center?

Is there a way for us to prove that this specific software does not randomly access device storage (while the app is running in the background / not active) and send the data to their data center?

First of all, the auditor should provide evidence that data is sent to a data center. Failing a security audit based on the assumptions that an application might send data to a data center is not valid. The audit should be all about facts.

Network Traffic

In order to monitor possible HTTP traffic of this mobile application, one could use an intercepting proxy for example. The certificate of this proxy is loaded into the phone and should be trusted in order to capture the TLS data streams.

Configure the phone to use a proxy server and point it to the IP address of the machine that is running the proxy.

Side Note: Make sure the intercepting proxy server is listening on an external network interface in order to accept connections from the phone. Any web based traffic should be captured now and displayed in the intercepting proxy.

When HTTP is not expected to be used as a communication protocol, it will be a bit more difficult to analyze the communication stream. In that case I'd suggest use a Pinapple device. Connect the phone to the device over WiFi and use TCP dump to capture its traffic.

TCP dump allows you to store the network capture in PCAP format. This PCAP can be loaded in a tool such as Wireshark in order to analyze all traffic.

Data Storage

First of all, requesting storage permissions should not fail an audit. It can be perfectly legitimate for the application to (temporary) store data on the storage device.

Again, it should be proven that the application could maliciously do things on the storage device.

Analyzing the application

In my opinion the best way to analyze the application is by reviewing the source code. If the source code is available, this is the best and fastest way in order to determine if data is sent to a remote server and if it will randomly read data from a storage device.

In case the application source code is not available, it could be decompiled and analyzed (I'll leave the law out of this for now and focus mainly on the technical details)

Conclusion
I cannot stress this enough: It is the auditor's responsibility to prove that the application performs malicious actions. Assuming an application might be malicious is not good enough.

The auditor should be provided with a security assessment report that is performed on the application. Based on that report, the auditor can state whether the application is malicious or not.

It's all about the evidence!


How likely is to have a hash function output flip a bit? I was looking into this code base (https://github.com/vstoykovbg/doubleslow) and the following phrase caught my attention:

DANGER of catastrophic data loss! One bit flip (due to cosmic rays for example) can make the result of the hash functions completely different. Run the scripts several times to confirm that they produce the same output given the same input. Read how these scripts work and why the risk of bit flip is high (hint: RAM usage).

Should we be hashing inputs more than one time to avoid this kind of issue?

It is very unlikely that the bit flip happens during hashing - which is a very short time and there are only comparably few instructions involved compared to the preceding processing of the input. It is instead much more likely that any bit flips already happened before, i.e that the hashing is already done on corrupted input.


Modified NMAP script: variable 'host' is not declared I am modifying an nse script, ssl-cert.nse, which was already made for enumerating ssl certificates. I want to output the host ip and the port number in a line of the ssl certificate output. However, any time I try to make a call to host.ip or port.number, it appears that host and port are undeclared variables. How can I output the current host ip and port number of the detected ssl service. Preferably I could concatenate the host and port number inside of the certificate data output. Below is the area of code I have modified / added to in the ssl-cert.nse script file.

        local out1 = host.ip
        local out2 = port.number

        output = function(host, port)
          out1 = host.targetName
          return host.ip
        end

       output2 = function(host, port)
          out2 = port.number
          return port.number

        end

      if nmap.verbosity() > 0 then
        lines[#lines + 1] = "Issuer: " .. stringify_name(cert.issuer)
      end

      if nmap.verbosity() > 0 then

        lines[#lines + 1] = "Public Key type: " .. cert.pubkey.type .. " " .. out1 .. ":" .. out2
        lines[#lines + 1] = "Public Key bits: " .. cert.pubkey.bits
        lines[#lines + 1] = "Signature Algorithm: " .. cert.sig_algorithm
      end

      lines[#lines + 1] = "Not valid before: " ..
      date_to_string(cert.validity.notBefore)
      lines[#lines + 1] = "Not valid after:  " ..
      date_to_string(cert.validity.notAfter)

At the bottom you will see return output_tab(cert), output_str(cert) this is the main code which calls the local functions. You want to edit output of output_str function so change the call as output_str(cert, host, port) and local function output_str(cert, host, port) than it will work.

For full example you can check following code. Replace source code from 230-end with following and it will work (it worked at nmap V7.7).

local function output_str(cert, host, port)
  local lines = {}

  lines[#lines + 1] = "Subject: " .. stringify_name(cert.subject)
  if cert.extensions then
    for _, e in ipairs(cert.extensions) do
      if e.name == "X509v3 Subject Alternative Name" then
        lines[#lines + 1] = "Subject Alternative Name: " .. e.value
        break
      end
    end
  end

  if nmap.verbosity() > 0 then
    lines[#lines + 1] = "Issuer: " .. stringify_name(cert.issuer)
  end

  if nmap.verbosity() > 0 then
    lines[#lines + 1] = "Public Key type: " .. cert.pubkey.type .. "  " .. host.ip .. "  " .. port.number
    lines[#lines + 1] = "Public Key bits: " .. cert.pubkey.bits
    lines[#lines + 1] = "Signature Algorithm: " .. cert.sig_algorithm
  end

  lines[#lines + 1] = "Not valid before: " ..
  date_to_string(cert.validity.notBefore)
  lines[#lines + 1] = "Not valid after:  " ..
  date_to_string(cert.validity.notAfter)

  if nmap.verbosity() > 0 then
    lines[#lines + 1] = "MD5:   " .. stdnse.tohex(cert:digest("md5"), { separator = " ", group = 4 })
    lines[#lines + 1] = "SHA-1: " .. stdnse.tohex(cert:digest("sha1"), { separator = " ", group = 4 })
  end

  if nmap.verbosity() > 1 then
    lines[#lines + 1] = cert.pem
  end
  return stdnse.strjoin("\n", lines)
end

action = function(host, port)
  host.targetname = tls.servername(host)
  local status, cert = sslcert.getCertificate(host, port)
  if ( not(status) ) then
    stdnse.debug1("getCertificate error: %s", cert or "unknown")
    return
  end

  return output_tab(cert), output_str(cert, host, port)
end


Is there any ability to determine the exploit used by compiled binary? I have a binary file which uses some exploit(i guess, it was generated with metasploit), but I can`t determine the exact exploit it uses.

The disassembly listing of it contains a plenty of "mov" operators, and .data section contains a lot of strings like:

  "!!\"#$$%&''()**+,--./0112344567789::;<==>?@@ABCCDEFFGHIIJKLLMNOOPQRRSTUUVWXXYZ[[\]^^_`abbcdeefghhijkklmnnopqqrsttuvwwxyzz{|}}~"

And assembler code consists of plenty "mov"s

Is there any way to define which exploit this malicious binary uses?

Based on further discussion with the OP, the answer to this question is that there isn't enough information to determine the exploit this payload was used in.

The best bet would be to forensically image the machine that it was used on (if available) and perform a complete analysis of the device including generation of timelines which should be reviewed for correlations regarding the appearance of the binary.

Secondary methods include scanning the system it was used on for vulnerabilities and trying to identify which exploits could have been used on this system. Narrowing it down from there. Much less reliable than the former.


How the AWS signature works in depth I'm trying to understand how the AWS signature 4 works. I read the docs and I found a Python example where a signature is computed.
I also ran into this answer which explains HMAC a bit.

I'm curious to understand what AWS does on the server side to "believe" in the request.

Are they running the same code as the example but setting the date with the parameter passed by the request and then matching the two hashes (HMAC seems to work that way)? If so, why are there so many values and two-step hash in the request (my guess is that is something related to the hash clash)?.

PS: since the approach (HMAC) uses ACCESS and SECRET keys as keys (it's symmetric key) it can be implemented only on a server side. This can't be done safely in a mobile app since the keys can be easily accessed. Is there a way to do so in a "less closed" (compared to server) environment such as a client app/mobile/etc. app?

The general Amazon API model involves the following steps

Build your API request with all the elements (within a program structure like an array)
Order and format the request elements
Calculate the HMAC of the formatted request
Send the full request to Amazon, with the HMAC

Amazon then takes the request, generates its own HMAC, and if it matches, it validates the request (provided your authentication tokens also match).

There's no way to ensure your security if you put your keys within an app. You would have to force any compiled client to contact your server and do the API request there.


What are the consequences for deceptive practices against stated privacy policy Disclaimer: I'm aware my question is a bit far from IT security practices but here is the most appropriate place I can think of to post my question within the whole stackexchange.

Let's say, many companies and websites post their privacy policy, normally in a link named 'privacy' or similar at the bottom. In such a privacy policy, many aspects are provided, e.g. information collection, sharing, disclosure, retention, security protect, etc.

However, I want to know, if a company/website deceptively practice against its stated privacy policy, what are the consequences?

For my knowledge, e.g. in the US, Federal Trade Commission can bring action against such practice. What about Europe? And what about other aspects rather than legal?

In most cases the provider will do the minimum necessary for compliance - be it compliance with legal requirements or with the binding industry standards they require to operate (such as PCI-DSS). If you have evidence that the provider is not complying with these requirements then the route to address these would be via the body which sets out these requirements. However I suspect that proving non-compliance would be rather difficult in most cases.

All the countries in the EU have very specific requirements regarding data privacy. And certainly within the UK there have been several instances of companies being fined for non-compliance with the data protection act.

However (IANAL) there is also a contractual issue between the provider and the user if the provider makes false claims about the security it provides. But since the provider is unlikely to go any further than the requirements previously described, then its unlikely that you'd need to exercise your options in this scenario.


Can a web-filter track my internet access over application API calls? I'm at college where each student has a login ID and password for internet access through the CyberRoam web filter for blocking certain websites.

My question is, when I'm browsing Facebook, YouTube, or Wikipedia through their respective mobile apps on my phone, can the CyberRoam client track what I'm viewing through the application's API calls? How does this compare to the data collected by CyberRoam when I browse the internet through my computer's web browser?

If your connection is https:// rather than http://, CyberRoam should not be able to see the content you are viewing.  It will just know the website.

If your connection is http://, anyone can view your content, not just CyberRoam.

Facebook, Youtube, and Wikipedia all use https://  by default.  So the content on the three example sites you listed should look like gibberish to CyberRoam.

If you want to get around the filter they use to block websites, use a VPN.


How safe is it to allow key-based SSH access within LAN? So this is my setup:

We have a few machines in a LAN, used for computation, which me and my colleagues access from the outside with SSH.
All our accounts on the LAN machines are managed and shared via LDAP (resides in the LAN, but is only accessible with SSL).
Access from the outside is restricted through one of the machines (SSH on port other than 22 and runs Fail2Ban). Password authentication is disabled and all users use passphrase-encrypted keys when logging in from outside the LAN. Root login is also disabled throughout the network.

However, as it is common to switch from machine to machine, many users use paswordless login within the LAN. This means that if an attacker gains access to that outside-facing host, he has the same level of access throughout the LAN as the user which was compromised.

How can I mitigate this risk? What are some good practices to follow? Are there other glaring issues with my setup?

You can use SSH Jump host (ssh -J) to connect to the internal machine via the external facing machine. This setup means that the key materials resides in your workstation instead of on the gateway. When using jump host setup, your local workstation negotiate the SSH connection to the internal machines directly, so an attacker that pwned the jump host cannot intercept the connection to your internal machine.

If you want to initiate connection after you are connected to the gateway, you can instead use agent forwarding (ssh -A). Note that this is less secure than the jump host setup, as an attacker that pwned the gateway can in use the forwarded agent socket to create new connections to the internal machine. To protect against this, you can configure your local ssh agent to display confirmation dialog before the agent needs to sign a new connection. Note also though, under this setup, the gateway can intercept communications as the session will be decrypted by the gateway before forwarding to the internal machine. In general the jump host is preferred, but there are situations where agent forwarding makes sense, for example, if you need to transfer files directly between the jump host and the internal machine, instead of having to route through your local workstation.


What are the potential vulnerabilities of allowing non-root users to run apt-get? There are two ways I can think of doing this:

On a system with sudo, by modifying /etc/sudoers.
On a system without sudo (such as a Docker environment), by writing a program similar to the below and setting the setuid bit with chmod u+s. apt-get checks real uid, so a setuid call is necessary.

...
int main(int argc, char **argv) {
    char *envp[] = { ... };
    setuid(0);
    execve("/usr/bin/apt-get", argv, envp);
    return 1;
}

I have two questions:

What are the potential vulnerabilities of allowing non-root users to run apt-get?
My goal is to allow people to install/remove/update packages, given that apt-get lives in a custom non-system refroot and installs from a custom curated apt repository. Are there safer ways to allow non-root users to run apt-get on a system without sudo?

apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

From GTFOBins

This gives you a root shell on the system. No creating packages and adding fake repos; this will give the user who runs this command easy and simple access to root.

So, in answer to your question, you are effectively giving root to every user who has access to this binary. If you are willing to do this, then you might as well just give them sudo access or the root password.


PCI - what qualifies as public access? My development staff is in the process of automating our end of month process.
There is a small manual step that needs to be executed.

We have been thinking about the PCI ramifications for making this accessible over the net. Looking at the PCI standards, notably 1.1 blocking public access to cardholder environment from the public internet.

I read that this wouldn't be considered publicly accessible if I have client certificates in place. This would place this more into the realm of VPN access and the associated rules.

Does this sound correct? Are there any additional gotchas I should look out for?

EDIT:

Perfect. Many thanks. I do have a firewall / HIP / NDS / etc all in place. The way I'm thinking the certificate authentication ( in conjunction with normal password auth) would be being used in lieu of a full fledged VPN tunnel. The certificate authentication would occur at the firewall, before anything dangerous can get into the internal network.

You can't use certificate-based authentication to "hide" a machine in the same way that a VPN hides a machine -- which is what the PCI Standard intends in section 1.3 in v2.0 of the PCI-DSS Standards.

1.3. Prohibit direct public access between the Internet and any
system component in the cardholder data environment.

Each of the components of 1.3 refer to avoiding direct contact with the system component.  Direct contact means that your machine has a publically accessible IP and can be communicated with directly.  A certificate-based authentication system does not preclude section 1.3 because it offers no protection against OS/network-stack level (or similar) vulnerabilities which could be used to penetrate and avoid the authentication system.

The sub-requirements go on to describe specific methods that must be in place to prevent public access -- intervening network-level protections such as firewalls, VPNs, etc.

If you have not already read it, please read "Understanding the Intent of the Requirements" as an interpretive guide.  Section 1.3's interpretation basically says exactly what I said above:

A firewall's intent is to manage and control all connections between public systems
and internal systems (especially those that store, process or transmit cardholder
data). If direct access is allowed between public systems and the CDE, the
protections offered by the firewall are bypassed, and system components storing
cardholder data may be exposed to compromise.

Ultimately, this means that as long as your manual system is protected with an intervening security firewall or other masking solution (eg. VPN) that also conforms to the requirements laid out in (all of) section 1, then you should be fine.  You wouldn't even need to use certificate-based solutions as long as all of the other identification & authentication pieces are securely implemented as per the PCI standard.


Decrypt TLS 1.2 traffic between .NET Windows applications I have attempted to decrypt traffic between two .NET applications (both on Windows platforms) using Wireshark but due to the Diffie Hellman with perfect forward secrecy, I cannot use my private key from the server to decrypt the session keys. The applications are communicating using HTTP over TLS 1.2.
My only hope is to get hold of the pre-master secrets from either the client or the server to do that. Unfortunately I have not been successful in this endeavour.
My need is to be able to observe what happens over a network and not necessarily see the contents of the messages but I do need to be able to identify requests which I only seem to know how to do when it is decrypted.
I know that Chrome and Firefox browsers can export a sslkeylog file that can be consumed by Wireshark if I set an environment variable SSLKEYLOGFILE to do so. This is useful to know but it won't help me in my case. I have a .NET client and server component and I've tried to google for ways to get IIS and .NET to extract those secrets but to no avail (they do have a feature request logged for .NET Core/5). There is a way using the SslStream and combining it with Bouncy castle's library but I am not using the TcpClient so that won't help me.
My only avenue (that I can think of) is to setup a reverse-proxy on the client side and let my client app  connect to this reverse-proxy and let this reverse-proxy do the call and extract the secrets as well.
I came across this question where people have answered by saying that nginx can be used to "intercept" the call and then write out to a sslkeylog file. You either attach the gdb to the running instance and hook in to some callback event OR you use some workaround by using a library that can override the existing library that nginx would have used. Problem with all those are that they are for Linux environments and not for Windows.
Is there a way for me to achieve the same but from a Windows perspective? I almost want to say using any tool, method, etc. (to get hold of the pre-master secrets)
I have noticed that there is this solution which is great if I need to look at the message dump (and there are ways to do that without using this method) but it only confines itself to the application itself.

Assuming the applications aren't using certificate / public key pinning (or that you can alter the pins if they are), your best bet is almost certainly an intercepting proxy.
There are a number of intercepting proxies out there, but I'm most familiar with Portswigger's "Burp Suite" and the free version of it will work fine for this, so I'll generally assume you're using that (you could probably also make Fiddler or Zap work here). I'm going to write these instructions from the assumption that you've never used an intercepting proxy before, but note that there are tons of guides online to how to use these tools.
Install the proxy on a machine in the same network as your two applications (it can be on the same machine as the client - the one that sends the requests - but you will need to change the server app's listening port or the client's request port if you want to install it on a machine that ever acts as a server) and start it up. If you're using Burp, it's a Java app and will run on anything (Win/Mac/Linux/etc.) with a suitable Java installation. The proxy will generate a "fake" CA key pair for HTTPS; you'll need to export that public key and install it as a trusted root certificate authority on the client machine(s). Set the browser proxy settings to use the IP address and port where Burp is listening (let its listening port through the firewall if needed) and test whether you can browse HTTPS sites using the browser, and whether they show up in Burp's log. If so, you're good to go.
It's possible your .NET app will respect the system proxy setting, in which case you don't need to change anything else; when it tries to talk to the server it will route through the proxy, and you can see everything it sends and receives. However, most apps aren't proxy-aware. To handle that, you can set the proxy to run in "invisible" mode, where it just acts as a web server and forwards the request appropriately (you can also explicitly configure it to forward requests, as a "reverse proxy"). If your app listens on 443 or a similarly low-numbered port, you may need to run Burp as Admin/root. Once Burp is listening on the port that the client sends requests to, go to the HOSTS file on the client (\Windows\System32\drivers\etc\hosts on Windows) and edit it (will need Admin/root privileges). Add an entry for the hostname of the server, pointing to the IP address of the Burp proxy.
The client will now connect to Burp when it's trying to connect to the real server. Burp will accept the connection, negotiate TLS using its own certificates (this is why you had to install Burp's CA cert), log every request, and forward them on to the expected destination (the server) over its own HTTPS connection (which Burp opens as a client). Burp will also log the server responses, and forward them back to the client as its own responses.
If the server is identified only by IP address, you can either change the IP address in the client and configure Burp to forward requests to the real IP address (reverse proxy mode), or you can install Burp on the server and either make the server listen on a different port (which you'll set Burp to forward to), or change the client to send requests to Burp's port (which Burp will forward to the usual server port). In the very unlikely case that the server listen and client request ports are hard-coded and the server address is hard-coded and the server is identified by IP address rather than hostname... you'll need to use something like ARP spoofing to get the request routed to you, and set things up so your proxy intercepts traffic for which its IP wasn't the actual destination. This is totally possible - SSLStrip does it, for example, though not using Burp - but you'll need to look into how to set it up.

Now, with all that said, there are a few other options.

Install on the client a modified version of the System.Net.Security assembly, such that all traffic through a TLS stream is logged to a file or similar. This might be complicated by assembly signing requirements, which would mean you'd need to modify the executable as well. This is all possible but could be a hassle. Also, if you don't have such a library to hand - one might exist out there but I don't know of it offhand - you'd need to decompile the official library and modify it, or install a shim library.
Decompile the client and/or server assembly and just read what requests it makes/receives and/or responses it expects/returns. Unless obfuscated, decompiling .NET is quite easy - recent versions of Visual Studio include built-in support, or you can use a third-party program like JustDecompile or similar - and even obfuscated code can usually be figured out with some work (the public symbols can't be renamed or hidden, which helps).
Decompile the client or server assembly and modify the function(s) that handle HTTPS requests/responses to additionally log the request/response text to a file or similar. Then recompile the assembly and run it instead of the original version (just move/rename the original, don't delete it).

(Obviously, if you would get in legal trouble for decompiling, don't do it)


Will the OpenPGP key fingerprint change if the certificate is extended? Should the fingerprint of a renewed (extended) OpenPGP Key be the same? Is there any documentation on it (RFC)?

Quoting from RFC 4880:

  There are many ways possible for two keys to have the same key
         material, but different fingerprints (and thus Key IDs).

Specially the bold part, so I guess that changing the fingerprint would also result in changing the key ID hence make the key useless, correct?

OpenPGP Key IDs

OpenPGP key IDs (and fingerprints) are used to reference keys when performing several actions like requesting and sending keys, or when verifying ownership. For example, you'd exchange the fingerprint with the key's owner on a separate, trusted channel to make sure the key really belongs to the person that claims to own the key.

The OpenPGP (v4) key ID is an identifier calculated from the public key and key creation timestamp. From those, a hashsum is calculated. The hex-encoded version is called the fingerprint  of the key. The last (lower order) 16 characters are called the long key ID, if you only take the last eight characters, it's the short key ID. An example for my own public key:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

The primary public key's ID is referenced in the pub line after the key size, in your case the short key ID is CB3AF6E6:

pub   4096R/CB3AF6E6 2015-12-24 [expires: 2016-12-23]

Be aware the eight byte short key IDs do not provide a sufficiently large value space, and it is easily possible to generate duplicate keys through collision attacks. Instead of short key IDs, use at least long key IDs, and when software handles keys, always refer the whole fingerprint.

For more details on how the hash sums are derived, I refer to RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints which also explains the differences for deprecated OpenPGP v3 keys.

Different Fingerprints/Key IDs for the Same Key Material

The RFC you're quoting refers to "many ways" to have the same "key material" have different fingerprints (and thus key IDs). First of all, one should discuss what "key material" includes; I'd suggest that the author was referring to the numbers forming the key only, not meta information like the key creation timestamp. Also, I'd not really consider the number of ways to get different fingerprints for the same key material as "many". I can only see two ways (without claiming the list to be complete, at least I should not have missed something obvious):

As already discussed above, v3 and v4 OpenPGP keys have different fingerprint calculation methods, so the same key pair will result in different fingerprints. This is also noted in the RFC:

  Perhaps
     the most interesting is an RSA key that has been "upgraded" to V4
     format, but since a V4 fingerprint is constructed by hashing the
     key creation time along with other things, two V4 keys created at
     different times, yet with the same key material will have
     different fingerprints.

Different key creation timestamps will result in different fingerprints. This is what was used by the Evil32 key collision attack to create lots of seemingly different fingerprints using few keys (key generation is expensive, while just iterating timestamps and calculating hash sums is cheap).

Will my OpenPGP fingerprint ever change?

  Should the fingerprint of a renewed (extended) OpenPGP Key be the same? Is there any documentation on it (RFC)?

  [...] I guess that changing the fingerprint would also result in changing the key ID hence make the key useless, correct?

If you extend the validity period, the fingerprint will not change at all -- you're neither changing the numbers forming the "key material", nor are you changing the key creation timestamp.

By extending the validity period, a special self-signature storing the expiry date will be issued. This signature has its own timestamp included, and will override any former expiry dates, so that any other user of OpenPGP will have the new expiry date merged into your old key.

Yes, if the fingerprint changes, your key would be rendered useless (in the sense that it seems to be another key), as the fingerprint is used as reference for both certifications and other usages of keys. But that's merely theoretical, as fingerprints won't change in practice.


How does my bank knows my second and forth chars of my password I see that the new login mechanism used by some banks in UK and also used by visa debit authentication is to ask for three random characters from your password at login (for example second, ninth and forth) but this surely mean that the password is not hashed, right? Maybe encrypted at best...
This is very bad, right? Or is there a way to hash a password and still calculate these characters? I cannot think of anything...

This stems from the times people would still use phone banking and an operator was required to ask a password. To prevent the operator from knowing the complete password, he would only receive three characters of the password and their positions.

It's actually not necessarily a bad thing if implemented correctly. You are correct stating that the password is not hashed. This scheme is called a masked or partial password. Some banks use this and the idea behind it is that in the event a client has a keylogger installed on his system, you will never get the complete password. It prevents the user also from storing it in an autocomplete or autofill tool.

Most implementations actually relay the passwords to another service running in the backend (meaning you don't talk directly to the database but to a seperate webservice).

Personally I'm not a fan of these schemes if they are not implemented together with a second factor of authentication. They completely fail at addressing most other malware than keyloggers as well as most social engineering attacks.


SSH keypair works in Putty but not in OpenSSH inside the Putty's session I created a key pair with Puttygen, I putted its public key under /home/tiesto/.ssh/authorized_keys, I loaded its private key with Pageant, and logged in successfully with Putty via port 22. The private key has a passphrase.

/home/tiesto/.ssh/ is tiesto-tiesto-755.

/home/tiesto/.ssh/authorized_keys is tiesto-tiesto-600.

The problem:

When I try to use the very same key pair from within the Putty session (to start a tunnel on port 80 as well) I am being asked for the passphrase; I can fill the exact correct passphrase 3 times and in the third time I'm being told:

  Permission denied: Public key.

The command I use to login seems basically like this:

sudo ssh tiesto@111.111.111.111 -L 80:localhost:80 -i /home/tiesto/.ssh/tiesto_pri @ arbpid=$!

(The arbpid=$! is a variable I added to mark the specific process, please just ignore it).

What's wired:

The same public key I use to start the Putty session is also under /home/tiesto/.ssh/authorized_keys.
The same private key I use to start the Putty session is under /home/tiesto/.ssh/tiesto_pri.

I double checked everything and don't know why it doesn't work.

You might have an idea what went wrong and why the very same key pair that works just fine for Putty, won't work inside the Putty session with OpenSSH for tunneling port80.

Putty uses its own privatekey format, called PPK, which is incompatible with OpenSSH. You can use puttygen to convert PPK to OpenSSH format (which is also OpenSSL 'legacy' format); see https://unix.stackexchange.com/questions/74545/what-difference-between-openssh-key-and-putty-key .

ssh unfortunately assumes any error reading a keyfile must mean the password is wrong, so it repeatedly prompts for the password when it can't parse the file at all.


Why is calculating the checksum of an IP Datagram header and then encrypting it not appropriate to provide Data Origin Authentication? So assuming Alice and Bob have agreed to use a particular symmetric cryptosystem and share an appropriate key, they want to achieve data origin authentication by computing the header checksum of an IP datagram and then encrypting it.

As far as I'm concerned this would be appropriate since

a) Bob will be able to determine that it was Alice that computed the checksum since it is assumed only Alice and Bob share the secret key.

b) When the checksum is then verified by Bob, he can be assured that the header was not modified in transit and therefore the source IP address is that of Alice's.

What am I missing?

Just to be clear, I am aware of IPSec but for simplicity I just want to consider IP.

Right after the first packet has arrived, any intruder may listen then reproduce the same packet header. That's simply the reason.

That's known as the replay attack.


What are the security implications of Digital Lifeboat (or other p2p storage solutions) From Digital Lifeboat's about us section

Our solution is a distributed storage cloud service. Digital Lifeboat will compress and encrypt each file selected for backup. We then process your encrypted file with an Erasure Coding algorithm that creates many fragments of your file. Once these fragments are prepared for transfer into the Digital Lifeboat Cloud, we then securely send and store each of them outside of your home on different computers. These encrypted, erasure coded, fragments are invisible on their storage hosts.
Using advanced steganographic techniques we safely store encrypted, erasure coded, fragments on your PC from other members of the Digital Lifeboat cloud. These fragments are invisible to your computer and it operates as if they are not there. When you add more data to your hard drive, they will automatically be erased if they are in the way.

What are the security implications of this setup? My dad is looking into it (and when compared with the cost of Carbonite, et al it looks pretty attractive) as a personal storage solution.
What risks could this setup have?

I remember someone being left with a bad impression about Digital Lifeboat in November 2012. His comment below was featured in the Security Now podcast.

  I recently started getting unsolicited and unexpected email from
  Digital Lifeboat, an online PC backup service.  It appears that
  somebody set up an account using my email address by mistake, so
  Digital Lifeboat have been sending me updates about the PC being
  backed up on the account, with links to their website.  If I wanted to
  access this person's account, with all of their personal information
  and all of the data in their backup files, I simply have to go to the
  Digital Lifeboat website and request a password reset using my email
  address.  It is just the customer's dumb luck that I am too scrupulous
  to do so.  Even if I don't do anything, though, they are still not
  getting any notification emails - I am - and they will never be able
  to reset their own password because everything goes to my email
  address.

  I tried unsuccessfully to contact Digital Lifeboat by email and their
  webpage so I could warn them about the risks they are taking by not
  verifying customers' email addresses during account creation, and
  possibly to find a way to contact the customer without invading their
  privacy.  But none of that worked.  So today I finally posted on their
  Facebook page and did receive a response from a man who initially did
  not understand the issue and then proceeded to tell me about an even
  bigger problem.

  He wrote, quote, "I forgot that our two-factor cell phone
  authentication is currently disabled.  When we disabled it, we left
  this gaping hole in our security.  Wow, that's our screw-up.  Thanks
  for bringing it to our attention.  I'd like to delete this thread so
  as not to advertise this issue, and we'll address it internally."
  That thread was deleted, but not before I took a screenshot of it.

  It worries me to think of all the people trusting this company with
  their personal information and backup data because they're not being
  told the truth.  Digital Lifeboat touts "256-bit AES encryption to
  insure complete privacy and security of your data," but what good is
  that encryption when they don't bother to protect the customer's
  account?  It's the same thing we were talking about earlier.  They
  clearly have awful security practices, and I'm still not sure they
  even understand the initial problem I brought to their attention.


Is it worth checking the referrer? I have researching CSRF and one thing on the list, I feel is questionable.  I am not sure if "checking the referrer" is worth doing or not.

Some articles I read, are saying something of this nature:

  However, this is risky, as some corporate proxies strip the referrer from all HTTP requests as an anonymization feature. You would end up potentially blocking legitimate users.

Other articles I'm reading say you should do it and consider an empty referrer as an attack.

My website does deal with multiple corporations and if its true that a corporations proxy can omit the referrer then I find it being a problem then an actual benefit to the website.

I'd say that using, lack of, referrer as the sole indicator of an attack is likely to be troublesome as you can't be sure that all clients will send it as expected.  In general using referrer as a protection against CSRF isn't considered a good idea as it can be spoofed under some circumstances.

If there were no other options then it might be worth using, but for CSRF there are better established mechanisms for protection (some info. here) such that in most cases the best approach is to use the framework's in-built protection mechanisms, unless you have a specific reason why those don't work in your use-case or are inadequate.