What does this javascript file do? Is this a virus?

Let's clean this up and look at it more closely, I've also replaced some HTML entities with their text equivalent:

Add a linked image to the page, Chinese characters were encoded but I don't think this is suspicious:

document.write('\n');

Initialize a bunch of variables, mostly with attributes about the browser and page, such as the HTTP referrer and the current URL, date, browser resolution, etc.

var a1156tf = "51la";
var a1156pu = "";
var a1156pf = "51la";
var a1156su = window.location;
var a1156sf = document.referrer;
var a1156of = "";
var a1156op = "";
var a1156ops = 1;
var a1156ot = 1;
var a1156d = new Date();
var a1156color = "";
if (navigator.appName == "Netscape") {
    a1156color = screen.pixelDepth;
} else {
    a1156color = screen.colorDepth;
}
try {
    a1156tf = top.document.referrer;
} catch (e) {}
try {
    a1156pu = window.parent.location;
} catch (e) {}
try {
    a1156pf = window.parent.document.referrer;
} catch (e) {}
try {

Appears to be looking for any existing cookies set by this application in order to keep a count of how many pages have been visited. This value is incremented and stored in a cookie.

    a1156ops = document.cookie.match(new RegExp("(^| )a1156_pages=([^;]*)(;|$)"));
    a1156ops = (a1156ops == null) ? 1 : (parseInt(unescape((a1156ops)[2])) + 1);
    var a1156oe = new Date();
    a1156oe.setTime(a1156oe.getTime() + 60 * 60 * 1000);
    document.cookie = "a1156_pages=" + a1156ops + ";path=/;expires=" + a1156oe.toGMTString();

It basically seems to be trying to record how many distinct pages you've viewed. Again it uses a cookie to help remember if you've already visited.

    a1156ot = document.cookie.match(new RegExp("(^| )a1156_times=([^;]*)(;|$)"));
    if (a1156ot == null) {
        a1156ot = 1;
    } else {
        a1156ot = parseInt(unescape((a1156ot)[2]));
        a1156ot = (a1156ops == 1) ? (a1156ot + 1) : (a1156ot);
    }
    a1156oe.setTime(a1156oe.getTime() + 365 * 24 * 60 * 60 * 1000);
    document.cookie = "a1156_times=" + a1156ot + ";path=/;expires=" + a1156oe.toGMTString();

Miscellaneous stuff, probably just to cater to differing browser capabilities and settings, such as cookies being disabled.

} catch (e) {}
try {
    if (document.cookie == "") {
        a1156ops = -1;
        a1156ot = -1;
    }
} catch (e) {}
a1156of = a1156sf;
if (a1156pf !== "51la") {
    a1156of = a1156pf;
}
if (a1156tf !== "51la") {
    a1156of = a1156tf;
}
a1156op = a1156pu;
try {
    lainframe
} catch (e) {
    a1156op = a1156su;
}

Write all this information as GET parameters in the source attribute of an image. Your browser will load this then their server can record the data.

a1156src = 'http://web.51.la:82/go.asp?svid=8&id=17211156&tpages=' + a1156ops + '&ttimes=' + a1156ot + '&tzone=' + (0 - a1156d.getTimezoneOffset() / 60) + '&tcolor=' + a1156color + '&sSize=' + screen.width + ',' + screen.height + '&referrer=' + escape(a1156of) + '&vpage=' + escape(a1156op) + '&vvtime=' + a1156d.getTime();
setTimeout('a1156img = new Image;a1156img.src=a1156src;', 0);

Basically it's tracking you, including the page you're viewing, how many times you've viewed the site, how many pages you've viewed, what your browser resolution is, etc.

This could be malicious depending on the circumstances, although most websites run tracking of some form such as Google Analytics. It doesn't pose a threat to the integrity of your machine as someone viewing the site, but it might be a threat to your privacy.

The odd variable names do make it seem like obfuscated malware, but I suspect this is to avoid variable naming conflicts with other JavaScript.


How can a Trusted Platform Module "enhance network security"?

Often the features of a TPM are not easy to leverage for non-programmers.  You could leverage a TPM in order to connect via SSH to a Web server; see a walkthrough guide at https://security.stackexchange.com/a/179422/68088

But average users can see an immediate benefit in encrypting their hard drive, for example with BitLocker. The private key which enables decryption of such an encrypted drive would be stored inside the TPM. The TPM has certain properties such as anti-hammering, isolation of keys and non-exportability which make it highly resistant to remote manipulation.


Do non-keyboard characters make my password less susceptible to brute forcing?

When I put this in a password, does it pretty much guarantee that it
  will never be brute forced?

A brute force attack on a password tends to happen one of two ways: either an attacker obtains a hashed password database, or an attacker attempts to login to a live system with a username (or other account identifier) and password. A common method of attacking hashed password databases is to use a precomputed set of values and hashes called a rainbow table. See What are rainbow tables and how are they used? A rainbow table is not a pure brute force attack because it uses less than the full domain of possible inputs. Since a true brute force uses attack every possible input, regardless of whether it is an attack on a hashed password database or a live system login, no character set selection or combination of different sets will make any difference to a brute force attack. Practically true brute force attacks are rare. Rainbow table attacks are more common, and using a value from a uncommon set will be an effective defense against many rainbow table attacks.

  am I right in guessing that attackers will never consider it worth
  their time to check non-keyboard characters? Is this even something
  they are aware of?

There are attackers out there who will use uncommon input sets to try and attack passwords, but I suspect they are rare. Any reasonably sophisticate attacker has thought about things like non-keyboard characters, and most make an economic decision to go after the easier targets. There are plenty of targets with poor and weak passwords, so attackers design attacks for these weak passwords. So, yes, many (but not all) attackers consider strong passwords not 'worth their time'.

  with a single non-keyboard character somewhere in your password you'd
  never have to worry about keeping the rest of the password strong.

No. Strength is a measure or resistance to attacks. If your password is a single non-keyboard character it is weaker than a password of 33 lower case characters. The length in bits is an important measure of password strength. Bits instead of characters, because cryptographic computations like hashes are done in bits, not in characters. A character set, like the set of non-keyboard characters, is only one element in making strong passwords, it is not strong by itself.


The way to determine IV for AES encryption, possible security problems with this approach

Assuming that echo $RANDOM returns good random value…

It does not. $RANDOM in bash is implemented using a LCRNG with 32 bits of state and a 15-bit output.


What is the difference between a RADIUS server and Active Directory?

Why would I need a RADIUS server if my clients can connect and
  authenticate with Active Directory?

RADIUS is an older, simple authentication mechanism which was designed to allow network devices (think: routers, VPN concentrators, switches doing Network Access Control (NAC)) to authenticate users.  It doesn't have any sort of complex membership requirements; given network connectivity and a shared secret, the device has all it needs to test users' authentication credentials.

Active Directory offers a couple of more complex authentication mechanisms, such as LDAP, NTLM, and Kerberos.  These may have more complex requirements - for example, the device trying to authenticate users may itself need valid credentials to use within Active Directory.

  When do I need a RADIUS server?

When you have a device to set up that wants to do simple, easy authentication, and that device isn't already a member of the Active Directory domain:

Network Access Control for your wired or wireless network clients
Web proxy "toasters" that require user authentication
Routers which your network admins want to log into without setting up the same account each and every place

In the comments @johnny asks:

  Why would someone recommend a RADIUS and AD combination? Just a
  two-step authentication for layered security?

A very common combo is two factor authentication with One Time Passwords (OTP) over RADIUS combined with AD.  Something like RSA SecurID, for example, which primarily processes requests via RADIUS.  And yes, the two factors are designed to increase security ("Something you have + Something you know")

It's also possible to install RADIUS for Active Directory to allow clients (like routers, switches, ...) to authenticate AD users via RADIUS.  I haven't installed it since 2006 or so, but it looks like it's now part of Microsoft's Network Policy Server.


I know this is a bit old, but in case other people are curious about these answers I thought I would post. I have performed side channel testing professionally for PCI-PTS compliance

1) Virtually anything can be obtained from a side channel attack. It is really just monitoring EM emission from a CPU for long wire.

2) a simply EM probe is typical, but monitoring power to a cpu can be used as well. A typical cell phone/laptop does not have the hardware to perform a side channel

3) side channel only involves data currently in use. When the CPU is operating on a key, for example, it emits small amounts of EM radiation. Used enough times  ~30k you can begin to do statistical analysis to start to uncover the information.

4)This is entirely Dependant on the Signal to Noise ratio of the EM /power. I have personally tested about a dozen cpus professionally and I would commonly start to see leakage around 30k, and by 100k uses, I would be able to derive an entire aes 128 key.

5) The EM probe needs to be within a few centimeters of the wire or cpu, or the SNR drops off to fast to be feasible. It would commonly take anywhere from 1 day to 1 week to obtain enough data from the machine, and about 2-20 hours of analysis.

6) It needs to be within a few cm for a probe. If using power we typically had to be on the downstream side of a good power supply to pickup any leakage meaning between the power supply and the CPU


How can I be as anonymous as possible while on Tor?

Use an alternate identity. Browse on TOR using a public connection and computer that is wholly separate from your home network. A VPN to hide your location might be a good idea as well.

Do not mix your identities in any way shape or form.

That will give you the most anonymity.


Is sending recaptchaPublicKey & RecaptchaToken in the post request a potential security threat?

Sending the extra fields in the request is no problem.  Depending on your server-side implementation, you might need them to validate the request.  You should have no need to reflect them, so this would not lead to an XSS.  In any case, this would not be a BREACH attack -- a BREACH attack requires that the attacker is able to control part of the page, and I fail to see how this would be the case with ReCaptcha.  (Unless you consider Google to be the attacker, but then including their javascript on your site would have given them access anyway, so it does not change the threat landscape.)


It boils down to whether there is a chance your authorization code might leak.

PKCE is about preventing leaked "authorization code"s from being useful. When you ask for an authorization code, PKCE requires you to send the hash of a nonce. When you redeem the code, you must provide the original nonce.

This means that a malicious actor (XSS or CSRF vulnerability) observing the authorization code request and response cannot redeem the code, as they don't know the nonce.

Edit: Additionally, the client_secret means that only your server can redeem authorization codes. But, anyone can send messages to your server! If the authorization code has been leaked, then that means you don't know who is sending your server the authorization code -- is it the person who initially asked for it or some eavesdropping app? Without checking the nonce, your server may end up using its client_secret to redeem authorization codes for an eavesdropper.


What is the best way to get a third party audit done of website security?

I'd echo what the other answers have said in that what you're describing is a fairly standard security review process and if done properly you shouldn't have much to worry about in terms of the audit company having access to your data.

A couple of points which may be of use

In choosing the company if there are any well-known industry bodies, you could consider using an accredited provider (eg, in the UK there's CREST ). as @D.W. says, testing companies are professional organisations and even an accusation of misusing customer data would be bad for them, so I'd expect most to be very careful with that side of things.
Contracts and NDAs should be in place between your companies. Part of that would of course include a requirement that they don't misuse any data from the test.
One point you mentioned about the auditing company making changes to your site.  Usually a security testing firm would just report results and make recommendations for change rather than actually altering a live system, and I'd say that's a good approach.  The audit company won't have a complete knowledge of your systems, so it could be risky for them to make changes to them.


Limit BitTorrent Sync connections to a specific network

If you are using Linux, iptables has a match called "owner" where you can apply certain rules based off the UID or GID of the process sending the data.

For instance:

Put the IP's or CIDR network addresses in a file (one entry per line)
Create a new user called btsync
Run the following:

#/bin/bash

RESTRICTED_IP_FILE="/some/file"

sudo iptables -N btsync_filter
sudo iptables -I OUTPUT -m owner --uid-owner btsync -j btsync_filter

while read ip; do
    [[ -n "$ip" ]] && sudo iptables -A btsync_filter -d $ip -j DROP
done < $RESTRICTED_IP_FILE

sudo -u btsync btsync

This will run btsync as the user btsync and all packets from that process that are going to a restricted IP will be dropped.


First: Base64 is NOT an encryption algorithm. It's an encoding mechanism i.e: Anybody can decode your encoded data.

Secondly: If you're facing XSS in your ASP app that means you're not sanitizing a user-influenced input properly. You will need to provide us with more details about the piece of code that is influenced by the user, but generally. you need to encode all input in html. That is:

" ----> &quot;
' ----> &#39;
< ----> &lt;
> ----> &gt;

In ASP you can simply use Server.HTMLEncode(string) to HTML-encode your user-influenced input.

Remember XSS can also be triggered from stored input, so you will need to sanitize those too!


Are NTFS Alternate File Streams considered a security risk in your organisation; how is it mitigated?

I have spoken with folks in a lot of corporates, and the majority are not looking at Alternate File Streams at all. The reason being in all cases that they have far simpler channels that still need to be controlled effectively and no extra budget. One client with a very effective DLP solution disallows any outgoing files or attachments, unless they have been preapproved - so they would be my best candidate to try this, however they don't have the infrastructure to easily implement this.

A problem is that you would need to automate the validity of AFS content - I don't know of anyone who has a solution yet. I guess you could whitelist all the apps that have a valid reason, but then a savvy individual could just use AFS in files associated with these apps.

The more I think about it and compare with other DLP attempts, the more I think it is a major issue unless you migrate extensively to thin clients (eg a fully Citrix'ed environment) or have an environment so locked down users can't get enough access to create AFS.


How sending email from same domain cause third parties to receive cookies

CNAME is like a domain alias, for example if you make email.stackoverflow.com a CNAME pointing to evil.com, anyone trying to access email.stackoverflow.com would actually access whatever server evil.com is pointing to. However, as far as the browser is concerned, it still thinks it's accessing email.stackoverflow.com, and will happily send all cookies set by the root domain, which could include sensitive session tokens.

By using a totally different domain (instead of a subdomain) they mitigate this risk and prevent their third-party e-mail/newsletter provider from getting user's session cookies.

The browser could send cookies if the user either explicitly clicks any links to the subdomain or if the e-mail is in HTML format and links to resources on that domain like images.


I found a malicious website embedded in Malware spam. What should I do?

Do a whois lookup on those domains, and see if you can find the abuse contact for the registrar. You can report it via that address. These may also be legitimate sites that have been hacked, so if it looks like they are you should contact the owners and tell them exactly where the malicious script resides.

You can also report the malware to Google's Badware page, which they can then use to prevent other users from accidentally getting exploited by the domain. Google also do a good job of researching these sites and often get a quicker result than you could yourself, since they have the right contacts.


How to check if an SSH private key has passphrase or not?

The keyfile will have a different header if it is password protected.  Here's the top of a key without a passphrase:

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEA3qKD/4PAc6PMb1yCckTduFl5fA1OpURLR5Z+T4xY1JQt3eTM

And here's the top of a key which is passphrase-protected:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,556C1115CDA822F5

AHi/3++6PEIBv4kfpM57McyoSAAaT2ECxNOA5DRKxJQ9pr2D3aUeMBaBfWGrxd/Q

Unfortunately, that only works looking at the files.  I know of no way for a server to be able to tell if the keys being presented to it were protected with a passphrase, which is the most useful place to be able to leverage that sort of info.


Setting up a honeypot to detect malicious network activity

It depends of the honeypot you are using. If you are using a low or medium interaction honeypot that only emulates some services, than the chances are very low that the attacker can break out of the honeypot (except if he finds a bug in the honeypot itself).

If you are using full interaction honeypots, like a real Windows machine, that the chances are high that the attacker could use the honeypot as a starting point for attacking other machines (on your network or on the internet). Therefore you must put a so called honeywall between the honeypot and the rest of your network which will basically block malicious traffic that tries to leave the honeypot. The honeywall is basically a combination of IPS/firewall/WAF of your choice.

Even if using a honeywall, you cannot be 100% sure that the attacker cannot break out of the honeypot. That is because you must allow certain traffic to leave the honeypot in order for the attacker to receive feedback from his attack, but you must prevent malicious traffic that could damage other machines outside of the honeypot to leave it. Finding the right balance is quite hard, and a risk always remains.


Cold-boot attack example in the real world

Yes, there are examples of cold boot attacks in the wild. An archived presentation gives an example of live memory acquisition on a server when DMA is not possible and when the native BIOS automatically initializes ECC memory at boot. The forensic investigators ended up writing a custom version of the open source coreboot BIOS and flashing it on the target hardware. This custom BIOS was designed to read memory and export its contents, lightly compressed, over a serial device. In order to get the new BIOS to run, they had to reset the CPU. I believe they were able to do that using the LPC bus. The end result was a low-memory footprint cold boot attack.

There are also examples of cold boot attacks being used on hardware you own in order to obtain valuable information to assist reverse engineering. Cold boot attacks have been used against various game consoles, and even prompted Microsoft to implement transparent memory encryption on their Xbox 360 console. The attack has also been attempted to view memory (UMA) reserved by the Intel Management Engine which is blocked from software access.


Is it preferable to wipe device first and then upgrade firmware, or vice versa?

Get recovery tool from original website or trusted source. Grab a memory card, scan it properly using antivirus tool using your laptop. Later flash the firmware from memory card, along with it wipe all data of mobile ( custom options are available in recovery). After the firmware is installed, remove memory card (before booting for first time). Factory reset it once it is booted for first time...

Note: Download original firmware from trusted site. Avoid using custom Rom's made by non-experienced user. You can use apps like "Netstat plus" to monitor your  device activity while you are connected to internet.

I have a personal experience, I have seen some custom ROM's tracking all my activity.


Any comments or advice on OWASP-2013 top 10 number A9

In a formal review of an application's security, all libraries should be vetted for security defects.   However,  this is not the point of OWASP-2013 A9.  The core of OWASP-2013 A9 is about having a policies in place to ensure that an application isn't compromised due to negligence.   OWASP states the following:

Identify all components and the versions you are using, including
all dependencies. (e.g., the versions plugin).
Monitor the security of these components in public databases,
project mailing lists, and security mailing lists, and keep them up
    to date.
Establish security policies governing component use, such as
requiring certain software development practices, passing security
    tests, and acceptable licenses.
Where appropriate, consider adding security wrappers around
components to disable unused functionality and/ or secure weak or
    vulnerable aspects of the component.

Number 2 is the most important.  If you are dependent on a library or platform,  these components need to be updated regularly.  Internally there should be a cycle to review all components and versions,  and ensure that these are fully updated.  A monthly cycle to review these components would be ideal.

In short number 4 is requiring strong validation of input to untrusted libraries.  If a library hasn't been fully tested for security defects then data passed to this library must be validated.  It is a very good security practice to do this for all input.  An example of this is using an OWASP ESAPI validation routine for all input.  So if it is an email address,  it should match a regex for email addresses.


Do PHP/SQLI Prepared Statements Need Special Character Escaping?

There is no need to do extra checks if you are using a prepared statement with parameters.  This is the industry standard for preventing SQL Injection in PHP.

With the example you provided you would be 100% protected (not 99.9%) from SQL Injection (at least based on what we know today, who knows what the future holds).

That said, there are circumstances where a parameterized prepared statement can still be vulnerable to SQL Injection, but to my knowledge these all involve the use of dynamic SQL which you aren't using here.

You can see OWASP's page on query parameterization here.


VPN and Domain Purchase from Compromised RDP

Yes, RDP over VPNs is the current method of choice for carders. Increasingly so due to many proxy configurations becoming much less effective than they used to be thanks to improved anti-fraud purchasing mechanisms.

They need a Windows machine on a clean IP to build a legitimate browser fingerprint and successfully fool a website's payment system into believing they're not a fraud.


What stops Google from saving all the information on my computer through Google Chrome?

What processes and systems are in place so that Google is not able to copy the data on my computer?

None. Google Chrome usually runs with the permissions of your user account. The application can then read and modify local files to the same extent your user account can. (These permissions apply to most of the programs you're using.) So you need to trust Google in that they don't ship a malicious update that spies on you, or keep sensitive files inaccessible to the account you're running the browser with. Alternatively, there are most likely sandbox implementations for your OS that let you run Chrome in an isolated environment with restricted access to the filesystem.

  What processes and systems are in place so that someone who writes a Chrome extension is not able to copy files on my computer?

Chrome extensions have limited privileges by default. An extension needs to explicitly request (declare) a permission to interact with documents on the file:// scheme.

Also note that your browser disallows ordinary websites to read or even redirect to file:// URIs. So while your local files are accessible to the Chrome process, they are not exposed to the web.


Has a benefit been demonstrated for credit card machines asking for ZIP code?

Is there any evidence that this actually leads to a significant reduction in successful credit card fraud?

Yes there is evidence, and Yes, it absolutely has resulted in reducing many types of card fraud:

The fraud prevention feature you are referring to is called Address Verification Service (AVS).  AVS service checks that the street number and/or the zip code presented at the terminal match the data present for the card holder at the issuing bank.

In real-time, the payment processor will return an AVS Response. Based on the response, the merchant can decide to reject a non-conforming transaction.

It has been adopted by nearly every card issuer in the US.

See Merchant Guide to the Visa Address Verification Service

The possible response codes, and the configurable reject settings are shown here:

In a gas station terminal setting, the terminal might be set to reject AVS Response codes N and A, for example.


How to hide information on a website from search engines?

If you want arbitrary people, who you cannot predict or define ahead of time, to access the page, then it needs to be unrestricted. If you don't want search engines from indexing the data, then you need to block automated processes from accessing it. CAPTCHA is a standard method for doing that.

But that still means that any human visitor to your site could find the information, and you appear to not want that either.

So, you need something that blocks automated processes, and is not easily discovered by human visitors, either. A random URL can work for this, and when you need to expose the information, you provide a link to the random URL. Change the URL periodically.


How important is CAPTCHA on registration pages?

My personal experience with ReCAPTCHA (widely regarded as being one of the best) is that it took about a week after we added it before the spammers we were trying to prevent figured out how to solve them.

They don't solve 100% of the presented images correctly but they don't have to.  Even getting one in every ten correct would be fine for them and they are doing better than that.  They are probably doing better than our customers.

There are some alternative styles of CAPTCHA that involve playing games or selecting the picture of a kitten out of several images.  These types of CAPTCHA have not yet seen any serious attention from dedicated spammers.

User enumeration may not be a solvable problem, depending on the design of your site.  In the case of a forum, an attacker simply needs to visit the forum and note down the usernames he sees attached to every post.

If anyone can register to the site, the registration process will have to notify the potential user that the name they have chosen is already taken.  A CAPTCHA will probably change the equation for an attacker here because the cost of solving it and the failure rate compared to the potential value of the enumerated credential would probably mean that it's not worth the effort.

Since usernames are generally the non-secret part of the credential pair, even figuring them out usually doesn't have much value for an attacker.


Protecting websites from outdated browsers and plugins via a whitelist/blacklist combination?

First off: This is absolutely the wrong way to solve CSRF problems.  CSRF vulnerabilities are a problem in your site, not in the browser.  Blacklisting certain browsers is not going to solve your CSRF vulnerabilities.  CSRF is not browser-specific and cannot be prevented through browser blacklisting.

Detecting browser versions: There are various ways to detect what browser version and plugin versions the user is using.  For browser version, you can use the User Agent.  For Flash, you can use the Flash player detection kit.  For Java, see Sun's java update check.  You'll want to check Quicktime, too, but I'm not sure how to do that.  Note, however, that detection of the browser version and plugin versions is difficult in Internet Explorer.

Knowing which versions are insecure: Maintaining the list of known-vulnerable browser and plugin versions is more difficult.  I think it's probably too much work to reasonably expect an ordinary site to maintain.  For browsers, a partial starting point is Yahoo's list of A-grade browsers, but they don't maintain which version is the latest known-good version and which versions are known to have vulnerabilities.

Suggestions: If you must check for outdated/vulnerable browser and plugin versions, I suggest that you look closely at  the Mozilla plugin check website, which checks whether you have any obsolete or vulnerable plugin version installed.  It supports Firefox, Safari, Chrome, and Opera, and partially supports IE.  You might want to copy or use their methods.  See also Mozilla's JSON interface to their plugin version database.

Bottom-line recommendation: I think you're asking the wrong question.  I think your question has some hidden assumptions and premises that are faulty.  Browser blacklisting is not an effective way of fixing or mitigating CSRF vulnerabilities.  And I think the question is unclear on the threat model.  I suggest that you re-ask the question afresh, this time starting with the actual problem you are trying to solve and the constraints you are working within, rather than making assumptions about what the best solution is (e.g., assuming that browser blacklisting is the best solution).


Are there any reasons for Kerberos being based on symmetric cryptography?

Full disclosure: I was the Program Manager overseeing Kerberos for a while, and am currently a developer actively working on it at Microsoft.

What you're describing is not strictly accurate. Kerberos as originally spec'ed does rely on symmetric crypto for authentication. However, there are widely used extensions to this spec that enables support for PKI authentication and defeats client *-roasting. Windows for instance uses the PKINIT extension for smart card auth and Windows Hello.

Additionally, the weakness is not that secrets are symmetric, but that the secrets are often user-generated which means easily guessable or they've chosen a weak cipher suite.  Switching to an asymmetric crypto-based protocol just moves the problem from "how do I generate keys" to "how do I store and protect keys". In practice both are equally difficult problems for different reasons.

Asymmetric keys also don't solve golden ticket-like problems. If you're in the position to steal the krbtgt symmetric secret, what stops you from stealing the asymmetric secret? Not a lot. If you're in the position to protect an asymmetric key, why aren't you in a position to protect a symmetric key? In fact many systems today use symmetric secrets for protecting these types of tokens, such as session cookies or refresh tokens because of the performance benefit. Making it asymmetric doesn't directly improve things (though app architecture could dictate otherwise).

Silver ticket problems do benefit from moving to asymmetric because a service would never need to know the private key, which reduces the likelihood of it leaking.

However, in doing so you give up a guarantee of mutual authentication. Symmetric algorithms have the property that because both parties know the secret there's mutual authentication (the system falls part when multiple parties know it). With asymmetric keys there's no guarantee the party that receives the ticket is actually who they say they are. You need to explicitly authenticate both parties now, which can be done by adding another asymmetric key, but now you have at least doubled the total number of keys required in this exchange. You're still stuck protecting a secret on both sides.

The alternative of switching to another protocol is also practically difficult to accomplish. There are systems that simply will never move, and the systems that will move will do so over many many years. This requires involving lots of standards bodies, software implementers, and companies, and convincing them all that  is best. That's not to say it's impossible or even a bad idea. Just that the effort required to do so and succeed is enormous.

Alternatively you can make minor adjustments to how Kerberos is used today and have Really Good (tm) security.

Ditch Passwords (smart cards, Windows Hello, FIDO, etc.)
Use strongly generated service account passwords (gMSA, etc.)
Disable weak ciphers (DES, RC4)
Enable compound authentication (armoring)


What advantage does the Bloomberg authentication system have over traditional 2 factor?

Disclaimer: I've never used these terminals before and the only knowledge I have of the system you're describing is the description itself.

How the authentication works

So here's what you're actually doing --

You log in to the website.
You provide biometric data to a fingerprint reader
The website provides some "challenge" value for the fingerprint reader
The fingerprint reader combines the biometric data it received with the challenge data provided by the website, and outputs a result specific to that particular combination of both your fingerprint and the one-time challenge
The website then reads that authentication code and verifies that the registered user is the one in front of the terminal

What is being protected

This technology is reasonably effective, but it doesn't offer the protection you might think it does. It's not there to protect you, it's there to protect Bloomberg.

Interestingly, this technology won't protect you from phishing or from fraud or from MITM attacks. But it protects Bloomberg from piracy.

Bloomberg terminals are notoriously expensive, and typically one terminal would be very useful not just for the person paying for it, but usually the whole office could benefit from access. So there's a certain incentive to "share" your subscription with your immediate coworkers. Bloomberg doesn't want this.

The fingerprint reader exists to ensure that nobody can use your login but you. Two-factor tokens can be shared; fingers can't. But fingerprint readers require hardware access, which a website won't have. So the fingerprint reader is designed to output a code you simply type into the website. You (Bloomberg) don't want to output the same code every time; so you need to mix it up with something.

You could use some independently-varying data like the current time (same as TOTP systems like Google Authenticator do, for example), but you (Bloomberg) want to ensure that the key isn't being generated by someone down the hall. You want to make sure that the paying user is sitting right there in that seat looking at that screen. So you send the fingerprint reader a unique challenge code for it to respond to.

Note that only the user is being authenticated; not the server, and not the connection. So in this scheme, a man-in-the-middle attack works just fine. Ideally the server could be authenticated with TLS, but since the TLS-verification artifacts aren't part of the authentication scheme, the authentication does not depend at all on that verification.

So this mechanism isn't nearly as helpful when your protection is important; it's no better than an OTP-based 2-step auth system, such as you'd get with SMS, RSA SecurID, or Google Authenticator -- but it's way more expensive. If it's your protection that is important, then currently you can't do better than the Yubico U2F key created by Google, but usable on any site that accepts it (including now Github!).


JSON Web Encryption - Authenticated Encryption

JWE specifies the use or RSA-OEAP for key encryption, not content encryption.  So you would still use an AEAD algorithm such as AES-GCM to encrypt the JSON, and the use RSA-OEAP to encrypt the key so that it can be securely transmitted to the receiver along with the encrypted data.

This mechanism still preserves the integrity of the data. All an attacker, even an active man-in-the-middle can do would be to fiddle with the encrypted key, the ciphertext, or the tag.   If any of these are tampered with, the authentication will fail, and the receiver will know that tampering occurred and that further decryption of the content is either not possible or not safe.


Is it safe to store session state of different apps in single Redis cluster?

Is it secure if we use one redis cluster for all clients using this app

The cluster will get you:

The ability to automatically split your dataset among multiple nodes.

The ability to continue operations when a subset of the nodes are experiencing failures or are unable to communicate with the rest of the cluster.

This makes the risk related to availability from CIA triad less. But, if the vulnerability/weakness exists with the application operating on database cluster or If the port accepting connection for redis is out in open, then the database consisting the data of multiple user for separate application may compromise. Also make sure you follow security advisory for the scaling, for example, if you are using twitter's nutcracker for horizontal scaling, make sure you go through security advisory.


Should I hash session IDs before storing the session contents?

LFI on session file is possible, but there are plenty of other options like /proc/self/environ, file descriptors, web server logs, raw database files, SSH/FTP/mail logs, an uploaded file or a temporary uploaded file located in /tmp is also possible, so you gain very little security through obfuscation from doing this. If the attacker can enumerate all session files they can just try all of them until one works. You would be better off spending the would be development time hardening your server or reviewing your code.


SSL certificates published in Mandiant's APT1 report

You cannot, generically, reliably rebuild the base certificate from which such a report was generated (apparently with the OpenSSL command-line tool). For instance, you have the string contents of the Issuer and Subject names, but not the information about how they were encoded.

You could use the signature as a discriminant for the certificates. You won't find a "normal" certificate with the exact same signature value (it is possible to build a fake certificate which contains the same signature, but you have to do it on purpose).

If you know the public key of the certificate which was used to issue this specific certificate, then you could use the public key to do the first steps of the signature verification, yielding the SHA-1 hash of the "To Be Signed" (that's a feature of PKCS#1 RSA signatures: this is an algorithm "with recovery": from the signature and the public key, you can obtain a hash of the data which was signed). With that hash, you could test whether a putative reconstruction of the certificate is correct or not. But this is hard work. If you just want to check whether a given certificate is one of the certificates in the Mandiant report, extract the signature field (e.g. with OpenSSL) and look it up in the lists published by Mandiant.


What are the potential privacy issues in using a TPM chip with GNU/Linux

The TPM compromising the OS is pretty unlikely. The chip talks to the host computer via a low-speed serial bus comparable to a serial port; the code handling data received on that port is much simpler than let's say USB-related code, so if someone wanted to own the machine they would rather use USB-based solutions (especially since you don't even have to exploit any vulnerabilities in USB-handling code as USB has a built-in vulnerability : it trusts any USB keyboard right away).

Now, whether the TPM is good at what it's supposed to be doing is a different issue. Personally I don't trust TPMs for full-disk encryption as the key is transmitted unencrypted over the LPC bus, so for someone with physical access to a machine (even turned off) all he has to do to own it is to connect a logic analyser to the LPC bus and grab the key from there. Once that's done the attacker defeated the FDE even though the machine was off, thanks to the TPM.

As far as other uses of the TPM where it generates and holds a secret key, it comes down to whether you trust the manufacturer to not have put in a secret command that would make the TPM spit out the key it was supposed to protect (or a "bug" that would allow running arbitrary code on the TPM), as well as trusting the manufacturer to have sufficiently hardened the chip against hardware attacks.


Creating self-signed certificate for localhost and trusting fully

As to the first part of your question. the answer is NO, and all who say it is forget that that also means breaking essential layers of security on the device.

as to the second   it is possible
but highly dubious to do so. The way to do this is by buying a certificate for a domain (like localapp.example.com) and have its DNS entry point to 127.0.0.1. and than share the key and certificate with the app.

Mind you, this effectively breaks the security layer TLS provides as the key is now on the same machine as the client. and anyone with access to the machine can listen in on that part of the conversation and use your certificate to setup there own service in its place.

I would recommend you get a NEW domain for this purpose and be aware this setup is only so that you can use your webapp in conjunction with your other web services. Which are now vulnerable to more injection attacks due to you having a local web service made part of the full app.


Spam email sent to my contacts pretending to be me.

You are looking at it in the wrong way. One of the following scenarios is probably happened:

The attacker gained your contact list and used their email to spam your contact list - In this case I suggest you look over apps/programs that are installed on the device you use for checking your email.
Attacker has hacked your email account and stole your contacts and then spammed them using their own email so your email provider wont block them (They might connect through an API or try sending all kinds of spam that your email provider might have blocked) - In this case I suggest you change your password and keep alert for any suspicious activity (You might want to check how they managed to hack you)

I also suggest you use haveibeenpwned this website to see if you were hacked.


The IP Authentication Header (AH) is used to provide connectionless
   integrity and data origin authentication for IP datagrams (hereafter
   referred to as just "authentication"), and to provide protection
   against replays.  This latter, optional service may be selected, by
   the receiver, when a Security Association is established. (Although
   the default calls for the sender to increment the Sequence Number
   used for anti-replay, the service is effective only if the receiver
   checks the Sequence Number.)  AH provides authentication for as much
   of the IP header as possible, as well as for upper level protocol
   data.  However, some IP header fields may change in transit and the
   value of these fields, when the packet arrives at the receiver, may
   not be predictable by the sender.  The values of such fields cannot
   be protected by AH.  Thus the protection provided to the IP header by
   AH is somewhat piecemeal.

AH may be applied alone, in combination with the IP Encapsulating
   Security Payload (ESP) [KA97b], or in a nested fashion through the
   use of tunnel mode (see "Security Architecture for the Internet
   Protocol" [KA97a], hereafter referred to as the Security Architecture
   document).  Security services can be provided between a pair of
   communicating hosts, between a pair of communicating security
   gateways, or between a security gateway and a host.  ESP may be used
   to provide the same security services, and it also provides a
   confidentiality (encryption) service.  The primary difference between
   the authentication provided by ESP and AH is the extent of the
   coverage.  Specifically, ESP does not protect any IP header fields

check those links for more details

https://tools.ietf.org/html/rfc4302

https://tools.ietf.org/html/rfc2402

http://www.amaranten.com/support/user%20guide/VPN/IPSec_Basics/Overview.htm


Why is it impossible to verify whether a file has been modified since creation?

I think you will want more of a philosophical answer than a technical one, given what you are rejecting.

A file is just a discrete collection of bits. Relevance and meaning are overlaid onto those bits by a human, but ultimately, it's just bits. How would it be possible to determine if the bits you have are in the same sequence in some unknown previous state? Answer: saving that state in a way that can be trusted to be used as a means of comparison.

That's why TLS/SSL uses 3rd party CAs to verify certificates, and why digitally signing files is useful. They provide a trusted means of having a state to compare. It's not perfect, but very effective if performed correctly.


when we can

that's usually the problem, here.

Even with access to the source code, it's not easy to reinterpret a program to find problem inputs.

In fact, it's one of the very hardest problems in computer science to "reverse" a program to see what input caused it to do something specific.

So, the reality is that even if it's sometimes theoretically possible to interpret the inputs to a program as symbols used in the program flow that lead to wanted (or unwanted) behaviour later on, it's usually much harder and time intense to find such symbols then just to try random input.


What's the minimal way of sharing your public PGP key in email signature?

If you have your publick key on key servers you can only share fingerprint, a link for download your public key is good if you haven't key on key servers or even when you have on key servers because maybe not all people use same key servers.

I use fingerprint and also I have a link to my public key on my blog.

gpg --recv-key B76036EDCAF1C2806B54F51F134C62027E67BBA2

Maybe also you can use key ID and it's possible search on key servers by email and check ID, but it's better to use fingerprint.


Somehow I am meant to be able to decrypt the application data by generating a private key using the information about the cipher and other info in ‘Server Hello’ packet

It does not work this way. If it would be possible to decrypt the TLS traffic just by combining information found in the packet capture then TLS would be terrible insecure since then essentially every passive attacker could decrypt the traffic.

Instead you need for decryption the private key of the servers certificate in case of the obsolete RSA key exchange. In case of the preferred DH key exchange even having this private key is not sufficient but you'll need to extract the secret specific for this connection from the client or the server. See Decrypting TLS in Wireshark when using DHE_RSA ciphersuites and SSL on Wireshark Wiki for more information.


I could place a file at a specific location I want. My first idea is to put some sort of hard coded paths in a zip archive.

It's not difficult to do, most zip archivers have a command line argument to specify hard coded paths. Example: pkzip -add -path=root ...

These vulnerabilities have been well documented https://wiki.sei.cmu.edu/confluence/plugins/servlet/mobile?contentId=88487470#content/view/88487470 .

Failure to specify the hard coded path during extraction might be caught as an "(E9) No file(s) were processed" error. Source: https://support.pkware.com/plugins/servlet/mobile#content/view/6488122 .

Any decent software checks for these attempts, once the software correctly determines where you want to write to it's up to the operating system to allow it; if properly configured the access won't be allowed.

This idea is too old to succeed, it will be blocked on many levels.

A user can't elevate their privilege by uploading a file or the web application has a serious security flaw.


CSRF in API calls from Javascript on the browser

IIUC only Ajax calls can set custom headers, and those are domain-restricted.

Btw CORS is not a type of protection, it is there to allow less protection (ie. let you make requests between domains)

So simply adding X-CSRF-CHECK: 1 onto your application's AJAX calls and having your backend such as PHP check for $_SERVER['HTTP_X_CSRF_CHECK'], you don't have to generate random tokens to prevent CSRF attacks since other Websites cannot set those headers. This is great since your forms can be easier cached now.

An attacker who can craft a header, will not have your session data since they won't be in your browser session with the server.

A CSRF attacker who cannot craft a header, though can use your session data will fail the X_CSRF_CHECK' header on your backend.


Relationship between DoT / DoH and HTTPS

If you want to hide your browsing activity from your ISP (and every other router that your traffic passes through), then you might want to consider using a VPN.  This will prevent your ISP from knowing which sites your are connecting to, as the ISP only sees that you are connecting to the VPN.  However the VPN will know which sites your are connecting to.  Some VPN's claim that they do not log this information, but this is difficult to verify.
As another option, you might want to consider using TOR.  With TOR, your traffic is routed through several nodes, so that no single node is privy to both your source address and your destination address.  See https://2019.www.torproject.org/about/overview.html.en for more info on how TOR works.


How to properly create and use cross-signed CAs and certificates

OK, this is the best that I came up with so far.

The problem with depth processing, I believe, is just OpenSSL's. It's not good that it can't build proper paths. RFC-5280, Sec 6.1 says:

  A certificate MUST NOT appear more than once in a prospective
  certification path.

OpenSSL probably violates that. However, I have to say that I don't quite see an explanation in RFC-5280 on how to build paths, except for its Sec 3.2; there are suggestion that paths must end with a single self-signed CA at the end of each chain (that, however, contradicts with statements that verification chain should not have trust anchors, but trust anchors may contain intermediate certs, which makes the post-chain side contain multiple certificates, where OpenSSL ends up with infinite loop). Either way, I don't agree with what OpenSSL is doing.

I also should say that what I was talking about is not just cross signed certificates, but mutually cross signed certificates. The obvious difference is that normal cross-signed don't create such a circular dependency, and is achieved by having a trust anchor from one CA that is signed by another CA (from the perspective of verifier, it's the same case as a trusted intermediary, AFAIU).

The way to make it work with OpenSSL, is by not adding cross signed certs into the trust list, but provide them as part of the intermediate certificates produced by the key holder.

If I put all self-signed in trust.pem, all cross-certs in untrust.pem, then verifier works, albeit spews intermediate errors (which makes sense as not all trees build/verify successfully):

Here is with both roots present:

$  openssl verify -verbose -CAfile trust.pem -untrusted nontrust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK

Here is with only one or another root present:

$  openssl verify -verbose -CAfile ca1/ca1.pem -untrusted nontrust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK
$  openssl verify -verbose -CAfile ca2/ca2.pem -untrusted nontrust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
OK

Which shows the coolest part of the cross signing that we can nuke a CA, and still have original certs working.

HOWEVER

RFC-5246, Sec. 7.4.2 that documents TLS 1.2 says that the server has only one chain to present to the client (and vice versa). If the cross signed certs can not be part of the trust store, then then client has to provide multiple chains in order for the verifying side that there are options. So, yes, it works in theory, but not with SSL (it may work with other verification protocols, I didn't check), at least in OpenSSL implementation of it.


You are correct that tailoring a key stretching algorithm's strength to the available hardware resources is superior to using a fixed strength. This is actually implemented in some cases, such as the LUKS disk encryption standard, which will use approximately two seconds-worth of PBKDF2 key stretching.

Sometimes this is not possible. For example, an external storage device may be used on multiple machines with varying hardware specs. What takes two seconds on a powerful computer might take half a minute on a cheaper, lower-end system. In these cases, a fixed difficulty for key stretching is often required, using a difficulty that is low enough that low-end computers can perform the operations fairly quickly, while still being high enough to be a pain for attackers.


How to block I2P and Freenet to my network?

You won't have much luck. All of those are designed specifically to circumvent censorship. You may have very limited luck by simply downloading and keeping an up to date list of Freenet IPs and I2P IPs and blocking them, and an up to date list of Tor nodes with the "guard flag" and blocking them. This will not stop anyone for more than 5 minutes. Alternatively, you may be able to perform random searches of people who use more than a certain amount of traffic, if excessive traffic is a concern, or people who have a certain ratio of unexplained to regular traffic, and reprimand those who are caught using disallowed software, and write them up if they knew better.

The reason it'll be hard to block these software is:

Freenet can connect using random ports to people who are not identified in the Freenet network, called "darknet mode". It randomizes packet sizes and obfuscates the protocol to prevent detection.

Tor is even better at evading censorship. You say you just need to close ports or block certain IPs to block it, but that's not true. It can use bridges, which are unregistered Tor nodes that listen on random ports. They furthermore can obfuscate their traffic even better than Freenet can. This can range from simple encryption to traffic shaping to literally disguising traffic by encoding it as a stream of PDF files, or a stream of javascript/html, or a video stream in the Skype format, or even a stream of random dictionary words in plain text.

I know little about I2P, but I believe it can use similar traffic obfuscation technologies as Tor, as well as unlicensed entry nodes.

Note that both I2P and Freenet are self-contained networks. They cannot be used to access the outside internet, so there isn't a risk of them being used to browse Facebook or Pornhub secretly. I2P does have "outproxies", but I believe they are so few as to be almost useless. Freenet only works with internal Freesites and I2P only works with internal eepsites. Tor on the other hand works with both real websites and Tor-specific onion sites ("hidden services").

Lastly, please consider the reason you are trying to block these technologies. If you were asked to do so by your boss, or if it is taking up an excessive amount of traffic, it's totally understandable. But unless there are compelling reasons otherwise, privacy should be a valid reason to use such technologies.


Is PGP secure against a rogue keyserver?

A PGP key server is just a big wall where anybody can glue some piece of paper, to the view of all people who happen to walk along the wall. Nobody actually trusts the wall for providing any kind of assertion about the truthfulness of what is written on the papers; that's just a wall, an archetype of mindlessness.

A PGP public key might be trusted, or not, depending on the signatures by other key bearers that you will find on that key. This is the Web of Trust, the kind of PKI that PGP uses. Signatures are completely independent of how the signed data was stored and transferred, and that's the whole point: nothing in this system relies on the key servers to enforce any security property at any point; and, similarly, signed keys can be sent over emails, phone lines or even avian carriers: it does not matter.

The worst a rogue key server can do is to cease to do its job, e.g. by deleting some of the keys is contains. It won't have much impact, except that it would make it more difficult for people who do not know each other, and yet want to send emails to each other, to build chains of signed keys and gain some trust in their respective public keys.


How to check big video file if can't check it entirely?

Most file formats (such as videos) aren't going to execute code unless:

The file is somehow a valid executable and you purposefully execute it
The application viewing it (e.g. a video player) has a specific vulnerability, and the file contains crafted content to exploit that specific vulnerability

In either case, there is no way to give you an answer without knowing exactly what type of malware. For instance, #2 could be a vulnerability in the video header, or the video data itself, which could be any part of the file.

In general, if you aren't trying to execute a video file and your video player is up to date, you probably don't need to check your video files for malware.


IPSec optional advanced questions [homework] AH/ESP and Tunnel/Transport modes

#1 Transport Adjacency This is where you need the entire packet authenticated but also in ESP transport mode.

#2 Dynamic routing This is what happens when you need the tunnel end-to-end, but need the path through the untrusted network to be dynamically assigned (i.e. resiliency).


Antivirus connects to their server over port 80

Though it is over HTTP, and the ideal would be over HTTPS, any software providers communicate over HTTP and sign the communication. Let's take a step back and answer what SSL (and TLS) provides.

Encryption of content
Validation of non-tampering

To prevent tampering, may software providers digitally sign the content with a certificate or a GPG key and send it over HTTP.

The question then is why? Why not just use TLS? Oftentimes, this is because of network infrastructure can't support TLS or the mistaken belief that HTTPS is slower than HTTP.

What's the risk? Generally, if the content is properly signed (and validated), there isn't much risk. It's still not ideal, but the big part is repudiation of content.


How can salted passwords work if you don't "keep the salts in the system"?

In this report on the recent ParkMobile breach, the article has this comment from the company: “You are correct that bcrypt hashed and salted passwords were obtained... Note, we do not keep the salt values in our system...”

The article states that "spokesman" Jeff Perkins made this comment.
Per ParkMobile's website, Mr. Perkins's title is "Chief Marketing and Product Officer."
With all due respect to the marketing folks, Mr. Perkin's may not be completely up to speed on all the technical details of ParkMobile's password hashing, and may not be speaking with perfect precision. Therefore, one answer to your question might simply be that his statement is not technically correct.

If the salts are not "in the system", how could a system match a user-entered password to their salted hashes?

This is a reasonable question to ask, since typically one stores the salts along with the hashes for bcrypt. That is, typically, the format of the stored bcrypt output is:
$2b$[cost]$[22 character salt][31 character hash]

Therefore, typically, the salt would be stored in the same database as the hash.
Without seeing the actual data from the data breach it is hard to say for sure what is going on here.
One answer is just that Mr. Perkins is wrong. However, there are certainly other possibilities, such as:

By "salt" he actually means "pepper."
They separate the bcrypt outputs (for example at the "$" characters) and actually do store the hash in a different database than the salt. In this case they still need to store the salt, and maybe the "system" in the quote is the hash database rather than the salt database. Note that this possibility is complete speculation (and atypical bcrypt usage).


Designing single-sign-on with JSONP/CORS?

OAuth is flexible, and sometimes the OAuth flow is modified for application specific needs.  The most common two flows are 2-legged and 3-legged,  which if these flows are implemented correctly,  then they are generally accepted as secure.

The proposed CORS AJAX implementation of the OAuth flow violates two security requirements of RFC-6749 - OAuth 2.0 Authorization Framework. This deviation from the standard undermines the ability for the authorization server to properly validate the client, and the client's intentions.

There must be a control in place to prevent a malicious JavaScript client from falsifying interactions with the authorization server.  If the URL is supplied as an argument within a CORS Ajax request, rather then checking the HTTP origin header,  then a malicious client is permitted to lie about it's context.  Further more, a redirection is used for mutual authentication of the authorization server and the client.  Not having these controls in place is a violation of RFC-6749 - 10.2. Client Impersonation:

  A malicious client can impersonate another client and obtain access to protected resources if the impersonated client fails to, or is unable to, keep its client credentials confidential.

  The authorization server MUST authenticate the client whenever possible.  If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization  responses and SHOULD utilize other means to protect resource owners from such potentially malicious clients.  For example, the authorization server can engage the resource owner to assist in   identifying the client and its origin.

The OAuth flow must be initiated by the user.  The OAuth state parameter is used to prevent CSRF when establishing authentication.  Forcing a user to login to a web application is a useful link in a session-riding attack chain.  After a session has been established an attacker can control the newly created session using CSRF, or XSS.  The failure to prove the user's intention in this context is a violation of RFC-6749 - 10.12. Cross-Site Request Forgery:

  A CSRF attack against the client's redirection URI allows an
  attacker    to inject its own authorization code or access token,
  which can    result in the client using an access token associated
  with the    attacker's protected resources rather than the victim's
  (e.g., save    the victim's bank account information to a protected
  resource    controlled by the attacker).


Which information does a standard router see?

Of your three questions, the answers would be:

Yes
Yes
Yes

So if these are a worry, you need to look at mitigation. What would help is to use https in every possible case - this at least hides passwords and content, but doesn't hide which websites you visit.

Tor can help hide the websites you visit, so if that is a concern to you then yes, run everything through tor. Or you could set up a server on the Internet that allows you to connect to it via SSL and redirect to whatever website you want. This way all your neighbour will see is encrypted traffic to one IP address.

Download volume is something you can't do anything about - other than use a different route to get your data. Perhaps get yourself a router and connection to the Internet.

(Alternatively, don't go to any websites you would be embarrased by if your neighbours found out...)


Is BEAST really fixed in all modern browsers?

I don't think anyone knows of any way to exploit BEAST, on any of those modern browsers, so as far as anyone knows, those browsers are probably pretty safe against BEAST-like attacks.  On the other hand, the underlying weakness is still present, which leaves some room for concern about the possibility that someone might find a new way to exploit that weakness.

BEAST exploits a security weakness in TLS 1.0. The principled way to close the entire weakness is to update both the browser and the server to TLS 1.1 or TLS 1.2. At the moment, Chrome supports TLS 1.1; IE9, IE10, Opera support TLS 1.1 and TLS 1.2 if you set a special option, but support is not enabled by default; iOS 5 client supports up to TLS 1.2; Firefox and Safari do not. Unfortunately, both endpoints have to support TLS 1.1 before you can establish a TLS 1.1 connection, and today, few servers support TLS 1.1 or TLS 1.2. A few servers support TLS 1.2 (e.g., Apache with mod_gnutls; IIS 7 if you enable some special registry keys; Java app servers on Java 7), but only a very few. This means that it will be exceedingly rare that anyone can use TLS 1.1 or TLS 1.2 today. Therefore, the principled fix to the BEAST attack is not widely deployed today, no matter what browser you use.

For more details, see, e.g., TLS 1.0 JavaScript injection vulnerability (BEAST): what to do client-side?; Security impact of the Rizzo/Duong CBC "BEAST" attack; and What can I do about TLS 1.0 javascript injection vulnerability on my server?; How do I use OpenSSL to test for the BEAST attack?; Why was the BEAST attack previously considered implausible?.

That said, several servers have implemented some workarounds that help mitigate the known ways of exploiting this weakness in TLS 1.0. These workarounds are a "stopgap" that do not make the weakness go away, but they do prevent all known ways of exploiting the weakness. The primary mitigation is to ensure that both sides use RC4, instead of any block cipher based mode of operation. Servers can arrange this by changing the order of their ciphersuites.  You can test whether your server is configured in a way that should prevent BEAST using this SSL tester.

I can understand why you might have gotten the impression you did. The earliest attack exploited this weakness using WebSockets. A later attack showed how to exploit it using Java, too. Most modern browsers have now been patched to change how WebSockets works, so that WebSockets can no longer be used to exploit this weakness.  However, the underlying weakness is still present, and I don't think anyone would be terribly surprised if tomorrow someone discovered a new way to exploit the weakness without using WebSockets or Java.

Firefox, Chrome, Opera, IE also implemented the following mitigation for the BEAST vulnerability: send just one byte of application data in the first record (aka 1/n-1 record splitting for CBC). This is not perfect, but it should help a lot. In the long run, the right fix is to move everyone to TLS 1.2, but that will take time.

Another footnote: while many browsers are starting to implement support for TLS 1.1, there is a significant caveat. Just turning on TLS 1.1 or 1.2 causes compatibility problems with buggy servers. Those servers fail if a client indicates that it supports the newer TLS versions. Therefore, browsers try TLS 1.1, but if that fails, they try again using TLS 1.0. If TLS 1.0 fails, they will further fallback to SSL 3.0. This introduces a vulnerability: a man-in-the-middle can force both sides to fall back to TLS 1.0.


Should a web application return true http errors?

I'd say to not buck against RFCs in a vain attempt to provide security through obscurity, they'll create more headaches when someone plugs into your API and is receiving 200 codes when the server is really throwing 500s.

Honestly: if you somehow get a list of all my API signatures, I still wont care and will return 403s all day. Even on an open API your 500 messages should be generic enough that they don't really know what is going on to begin with other than "the server didn't like the input, please follow spec, etc. etc".


Are there any anti-virus programs that have a bot that clicks email links?

A number of anti-virus, anti-spam, and anti-phishing solutions work by visiting every link in an email and checking to see if the link leads to a suspicious-looking site.  Sometimes you can detect them by checking the user-agent, but more often, they imitate the user-agent of a well-known browser (typically Internet Explorer) to prevent malicious sites from detecting them.


Command prompt randomly opens and Closes really fast

If your version of Windows allows you to run Local Security Policy or Local Group Policy editor, you can enable advanced audit logging of process start and stop in the system, and the next time it occurs, look in the Security event log to see what process was launched.

To do this, run Local Security Policy editor (in "Control Panel"->"Administrative Tools") as Administrator (right-click on its icon and select "Run as Administrator"), and expand the left-hand tree "Advanced Audit Policy Configuration"->"System Audit Policies"->"Detailed Tracking". Select "Detailed Tracking", and on the right-hand side, double-click on "Audit Process Creation" to bring up the properties dialog. Tick "Configure the following audit events:", and "Success", then click on [OK] to save the setting. It should take effect immediately.

The next time the window appears briefly, record the system time (not the time on the clock on the wall), run Event Viewer (in "Control Panel"->"Administrative Tools") as Administrator (see above) and expand "Windows Logs" to select "Security". You should see a number of events; you're interested in the ones with Task Category "Process Creation" with Event ID 4688, at about the time that you recorded. You'll probably see a few events; look at the General tab in the details. You're interested in the Process Information bit, specifically the New Process ID, New Process Name, Creator Process ID and Creator Process Name. There should be a "C:\Windows\System32\conhost.exe" process, which is the Command Prompt window that you see. Its Creator Process Name value will tell you how it was launched. Look at the following events to find one whose Creator Process ID is the same as the conhost's New Process ID. That's the program that actually ran in the Command Prompt.

Hope that helps.


How to use mySQL UNION operator in sql injection, with injectable password paramiter?

The query takes two parameters, $user and $pass. As you can see, the $user variable is properly quoted, while the $pass variable is used as-is, which makes it vulnerable to Sql Injection. From the code it is evident that all we need to do is to return any value from the query in order to get access:

    if ($result->num_rows == 0) {
      $error = "Username/Password invalid

";
    } else {

Set the $user parameter to the name of an existing user, let's say 'admin', because it will be used afterwards by this code:

      $_SESSION['user'] = $user;

Set the $pass parameter to:

whatever' UNION SELECT 0,1 --

So the query becomes

SELECT user,pass FROM members WHERE user='admin' AND pass='whatever' UNION SELECT 0,1 -- '

Note the "-- " at the end of the query. This is a comment, which helps us get rid of the last single quote. The whitespace after the double-dash is required, otherwise MySQL won't recognize the comment. Alternatively you can use the # symbol. More info here: MySQL Comment Syntax


DOS attack to increase packets received from a single request?

Amplification attacks leverage the asymmetric nature of small amounts of data sent to servers producing a large amount of response towards a target. These are usually performed over protocols for which the source address is easily spoofed. This is not a strict requirement and certainly this could occur on a wide variety of protocols or services but the nature of being able to redirect traffic is what makes these protocols useful for attackers.

That said if you strictly want your dosfile.dat file to be used in a similar attack it would be easier to replicate this if you can insert it into a IP or UDP based service that can still allow for spoofing of source packets so the response can be redirected and sent to another system somehow. In theory, depending on the size of dosfile.dat you could create a DNS text record (or several) with this information and perform an DNS amplification attack of some form and that data would be included.

See the following for more information:

https://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack/


Why Oracle says following deserialization vulnerabilities are related to HTTP protocol?

You have to be able to trigger deserialization to exploit this. It is just saying that the protocol used when it is exploited is http. However, keep in mind that there are often default listeners that can be exploited. For example, JBoss allows for using adaptors for accessing MBean services over any supported protocols. For HTTP, the JBoss AS provides the HttpAdaptor. In a default installation, the HttpAdaptor is not activated. However, the HttpAdaptor's JMX Invoker is running and publicly available at the URL http://localhost:8080/invoker/JMXInvokerServlet.


What are the benefits to adding a bitcoin blockhash UID notation to one's OpenPGP key?

This is a great question, I'm not 100% sure, but my guess is that it's a proof of age that the PGP key is newer than 2013-10-19. My reasoning is as follows:

What makes blockchain mining computationally hard is fiddling with the nonce until the hash of that block has a specific number of leading zeros (16 hex zeros, or 64 binary zeros in this case). Once you find such a nonce for that block of transactions, you can publish the block and claim the bitcoin mining reward.

That hash is 64 hex digits = 32 bytes, or 256 bits. Currently there are 410086 block in the blockchain. That means the chances of guessing a random 192 bit hex value (256 - 64 bits of leading zeros) and having it match the hash of an existing block is about 1 / 10^52. So the fact that he embedded in his key the hash of a block from 2013-10-19 means that this block had already been published by the time he published his key; but there's nothing to stop him from having inserted that retro-actively.

In summary: this proves that the key was published sometime between 2013-10-19 and now.

I also notice that the key was first self-signed on 2012-04-25, but the blockhash wasn't added until 2013-10-19 and then the same blockhash has been carried forward ever since. I'm a little stumped to as to what that's proving. Why would you want to prove that you key is newer than a certain time?

If you want a definitive answer, then email him! I'm sure a bitcoin / PGP nerd would be happy to explain!


Test the XSRF patch on a GWT application

I've managed to test it with POSTMAN.
the tricky thing to notice is setting all the headers, especially the Content-Type that must be set to: text/x-gwt-rpc; charset=UTF-8.
I've taken a payload from a recent request, and then I done the same request with postman, the server answer with a legit peyload.
Then, I changed the rpc token in the payload request (I've taken it from the XSRF request during the loading of the app).
The served answered with a XSRF Token Error.

So, without a proper Token, no request can be done on the app.

One thing to nice is that the xsrf token is just the md5 of jsessionId, so another way to test it is to change the jsessionID in the chrome console or its md5.


The article Code Sample: Intel Software Guard Extensions Remote Attestation End-to-End Example (by John M. from Intel), describes an example of remote attestation. (The source code of most of the functions described in the article can be found here.)

Among others, the article mentions the structure of the remote attestation quote, sgx_quote_t:

  The structure of the quote is defined in sgx_quote.h:

typedef struct _quote_t
{
    uint16_t            version;        /* 0   */
    uint16_t            sign_type;      /* 2   */
    sgx_epid_group_id_t epid_group_id;  /* 4   */
    sgx_isv_svn_t       qe_svn;         /* 8   */
    sgx_isv_svn_t       pce_svn;        /* 10  */
    uint32_t            xeid;           /* 12  */
    sgx_basename_t      basename;       /* 16  */
    sgx_report_body_t   report_body;    /* 48  */
    uint32_t            signature_len;  /* 432 */
    uint8_t             signature[];    /* 436 */
} sgx_quote_t;

One of the members of the struct sgx_report_body_t (defined in sgx_report.h) is report_data, whose type is sgx_report_data_t.
report_data is the arbitrary information that an enclave can include inside its remote attestation quote. It is only 512 bits, so you would probably put there a hash of a public key (and send the public key itself alongside the quote).

Either way, if I understand correctly, report_data isn't encrypted by default.

Note that assuming the attacker cannot execute arbitrary code inside an enclave, they can't perform the classic MitM of a Diffie-Hellman key exchange (as described here), as they cannot create a quote with a valid signature.


Does using GUIDs for IDs make IDs unpredictable?

Let's go with the assumption you are using tokenization/encryption techniques sufficient to meet PCI DSS.

No we are looking at an abstract problem of can someone predict a value. The risk factor is that if the value can be guessed or follows a known pattern, one could then delete at will.

The issue of the GUID is irrelevant, because the attack vector is still a brute force attack. While knowing the pattern or algorithms used to create your unique id can certainly help reduce the possibilities to more of a dictionary-bounded attack, the knowledge of the ids ahead of time is not necessary to delete records indiscriminately.

You address the problem by implementing additional controls. First, if this is in a database, you have sufficient logging and transactions in place.

On the way to perform the deletion, there should be additional controls in place. Let's start for the user side: If the record is associated with the user, only the user should have the ability to delete his/her own records. If the user is not authenticated or does not own the records, do not allow the deletion procedure to continue forward. Does the user need to provide a special authorization? Is another variable set in the database or in a the session to allow the deletion (e.g., they need to authorize before the action goes throught?) If there is a sufficient risk, you can implement an out of band confirmation, such as sending a SMS message or maybe a confirmation via email is acceptable. In this scenario, its probably low risk if a user knowingly deletes their own credit card records because they can enter it in again later.

If you have strong authentication, authorization, and transaction controls it will limit the ability to indiscriminately delete values, even if they are known.

As an additional precaution, you may wish to implement heuristics and attack detection algorithms. For example, limit the number of deletions from the same IP address per day. Roll back transactions if there are too many deletions in a given day considering normal deletion patterns, etc.

It sounds from your description a simple POST command is being performed, I would ensure this only happens if there is TLS/SSL, the user is authenticated, there is a CSRF token in the request, etc. I would ensure that all deletes are logged and can be rolled back. Since the deletion would not result in exposure, you can also rely on a post-action notification to the users, "We Confirm you have deleted your credit card on file. If you did not do this, please contact us immediately" etc.


Clever.  I believe the idea is that it attempts to perform SQL injections against web pages targeted at SQL Server.  The idea is that successful SQL injections can be discovered by determining if they propagate out to web pages.  Any data / fields etc. that are leveraged by a web application or page will now display the unique string.  They likely look for the string immediately (reflected), as well as scanning the application or site afterwards (stored SQL injections).  One can even leverage your favorite search engine to find them (as you discovered).  Commercial web scanners use a similar technique to tag injections.

The first script updates all the fields in the DB with a unique string (edf40wrjww2) wrapped by some HTML.   The second script runs through all the fields updated by the first script and appends on specific information about the table and column that was compromised.  Not sure why this is split into two scripts - it might be to reduce the injection length, or to make sure that the length of the column can at least fit the tag.

If you use SQL Server you may want to check your DB for this string.


Only browsers (which interpret the HTML) will follow http-meta refresh tags and usually also only browsers will follow Refresh headers in the HTTP response header.

I have no idea why you consider Javascript based redirects a no-no. But if the reason is that it will only work in browsers then you should treat http-meta refresh tags in a similar way.

  And should I start marking meta-tag redirects as 'good'?

Since you don't explain what you consider 'good' in the first place it is impossible to say if redirects using http-meta fit your idea of 'good'.


Seems my CNAMEs got "curled". Somebody please explain this to me

Can somebody please explain to me how exactly this unscrupulous fella found my CNAMES?

No one can know, after the fact, how an UNKNOWN entity managed to get your UNKNOWN content.

There are a lot of ways to find out names in a zone, there are even tools for this.

This could be a good introduction on the subject: https://blog.appsecco.com/a-penetration-testers-guide-to-sub-domain-enumeration-7d842d5570f6

In summary it lists the following:

using search engines (the site: operator)
passive DNS services (that record huge volume of DNS queries, including possibly yours, hence "divulging" to others the name you have resolved yourself); some ISPs are also sharing DNS queries data (which is one of the strong motivation for people advocating to use DoH)
Certificate Transparency Logs
dictionary based enumeration, and other similar string manipulations
DNS zone transfers
DNSSEC walking (trivial with NSEC, possible but far more complicated with NSEC3)
various useful "side" information: DNS TXT records for SPF, DNS SRV records, various HTTP headers, etc.

You can certainly add others, like: domains are listed in the parent zonefile, which at least for all gTLDs, is free to get; once you have a domain name you can apply the previous points.

A tool that implements various ways: https://github.com/OWASP/Amass

This other article also lists some tools: https://geekflare.com/find-subdomains/

People also often forget how "chatty" by default their OS is, specially on smartphones. And what various browsers plugin can do and record...

In the same way, it is known for example that any link exchanged in Skype will get immediately scanned by some robot (in theory to identify if the link is risky or not). Which means that suddenly a third party will access your site (and hence know a website name) where you imagined no one else knew about it.


Is it safe to distribute the server's certificate file with the client?

The problem is that your server certificate is either self-signed, or signed by an untrusted certificate authority.  I'm guessing that when you created the certificate, you just did it yourself in OpenSSL, and you did not have it signed by a legitimate trusted certificate authority.  Because it lacks a legitimate signature, your client has no way to recognize the certificate is valid, which is why the client sees the "certificate verify failed" error.
To fix this, there are a few options.

The best would be for you to replace your server certificate with a new one signed by an actual Trusted Certificate Authority (one that your server and client already trust).  That way both your server and client will be able to trust your certificates and each other; now, and into the future.
An option that provides no security is to continue to include the server certificate with the client.  It's convenient, but it directly ties your clients to only that server and certificate.  Your clients will break when your fake server certificate expires, and they'll have to come to you for a new certificate.  What's to stop an attacker who says he's distributing a copy of your software, including his own certificates, promising that it's secure?  Nothing.  Your certificates provide no assurance that the client and server are genuine and are run by you.
A third option (that is even less secure) is to import a copy of your signing certificate into both your server and client's trusted root authority stores.  It's less secure because it exposes your clients to risk, because they'll then trust anything signed by your little fake certificate authority.  I would only recommend this as a good way to learn how certificates and certificate authorities protect your communications; I would not recommend this as a long term solution.


Difference between fully homomorphic and semi-homomorphic encryption

If you're happy with a more mathematical definition:

A Fully-Homomorphic Encryption preserves a ring-structure.

This means we have a Ring (R,+,*), where R are our bits on which we operate, (R,+) is an abelian group, while (R,*) is an monoid. With addition and mupltiplication over bits it's possible to create NAND gates. If you have NAND gates, you can derive every other boolean gate and therefore are able to do every computation on the encrypted data.

Semi-Homomorphic Encryption on the other hand only supports one operation and because of that you are not able to create NAND gates, which means you can't do every computation on the encrypted data.


How can spoofing a certain MAC address enable sending probe requests that I was never connected to?

My understanding is that your OS is doing what is called an active scan: periodically sending probe requests to discover the AP's around it. The MAC address or the history of your connections is not relevant in that case.


What are security problems with hole punching technique in the context of IoT?

Cloud based team viewer or similar solutions to remotely control a camera have risk of

how do you decipher a legitimate remote user and a malicious hacker with a stolen password logging in?
the cloud provider themselves could be comprised or have a vulnerability that gives an attacker access to your internal network.

More important thoughts are

do you have logging of every time it's remotely accessed?
is your camera segmented off so that even if an attacker remotely logs in they can't do damage to the core part of your network?
do you have 2FA/MFA required in the remote access cloud account so you can't be breached by a simple stolen password?


Random characters and letters form obsfuscation

No, you seem to have a misunderstanding of how encryption and obfuscation work. Encryption provides confidentiality: a message is hidden with a mechanism using a shared secret from all parties not possessing that secret.

Obfuscation refers to a number of techniques employed to make, in general, a scripting programming language application difficult to understand to a human reader. They take as input the application in its original (human readable) form, (a key) and output a functionally equivalent application, larger in code size and far more difficult to understand.

Now to answer your question, no it will not work as you mention there may be no authentication nor encryption, meaning that any passive attacker(using a packet sniffer and located in the same network as one of your potential visitors(i.e. victims) simply retrieves the password/javascript code in plaintext.


How safe is SSL on an untrusted computer and network?

Validating the certificate will be the least of your problems if you're using a computer that you do not have full control over. If you are really worried about security, the bigger problems would probably be:

web history buried deep within the hard drive (depending on the way information is accessed)
keylogger software
forgetting to log out of accounts

As for the certificate, other signs you can look for besides the name of the CA being a known, trusted organization are that the domain names match and that the certificate is not expired, both of which the browser is built to do. However, this aspect could be tampered with as well since the administrator of the computer can create an intermediate certificate and add their fake CA to the list of those trusted by the browser.


Is Google Keep more secure than LastPass Secure Notes?

LastPass encrypts everything locally on your PC and only sends the encrypted blob to the LastPass servers. Even if someone hacks into LastPass's servers, your data is safe, even your "secure notes" data.

That's not the case for Google Keep. If they manage to get access to Google's servers, presumably they will have access to anything you've stored in Keep.

This also means it would be harder for a disgruntled employee to leak your data, or a government/criminal organization from forcing/bribing/blackmailing someone into doing the same.

Additionally, I assume (perhaps wrongly) that secure notes can be obscured by default, whereas Google Keep leaves everything wide open for shoulder surfing. I'd rather "reveal" one security question at a time for a few seconds rather than have all of them for every site displayed on my monitor or phone for anyone to see.

I'm actually a little surprised LastPass doesn't integrate well with security questions and the like. Other password managers can store these and auto-fill them like passwords. I only know about KeePass (which takes a significant amount of setup to allow this) but I'd guess many of the managers offering form-filler features would allow this as well.


Is it inconsistent to tell users to "not click on password links in email", and requiring clicks on "forgot password" links?

You mention a very specific subset if phishing attacks related to fake password reset emails.

Assumption 1: you already have controls in place to reduce these inbound emails based on whitelists, SPF, whatever.

Assumption 2: you have controls in place to limit outbound website visits by your users to malicious sites.

Assumption 3: you are asking simply for a pattern (rule) to give to your users to help them decide when they should click a password reset link in an email vs being suspicious and not clicking... If not a pattern for users, then something more technical/automated.

Easy rule of thumb for users : Don't click password reset links in emails unless you are expecting to receive such an email.

If you receive an unsolicited password reset email, ignore/report it to IT.  If you request a password reset from SaaS application XYZ and you receive an email from application XYZ in the next few minutes, it is probably legit.