Multi-boot with full hard drive encryption and pre-boot authentication

Before you read all this, remember that this technique is at least 5 years old -- it's probably much easier by now (see the other answers). (But it sure was fun to figure this all out.)

I did this a few years ago with Fedora 10 and Windows Vista to demonstrate how all the intricacies fit together. It was a bit involved (mostly because Windows Vista doesn't "play well with others" and doesn't like being installed second), but in the end I found a method that suited me. Your case is more complex because you have 3 existing OS'es and you want to add another onto your drive.

Because I've never attempted this on the magnitude of 4 operating systems, I'll leave most of it up to you (the actual re-partitioning and such) and will try to take the general security principles from my experience and apply them to your situation. Also note that in my case, I started from scratch on a drive I had erased. This was more an experiment than an expert exposé... so take a few things with a grain of "salt" (no pun intended) and don't hold me responsible. :)

Remember, these are just my notes. You will have to adjust them for your situation. So here we go:

Problems overcome by the method described here

My notebook’s hard disk could only contain 4 primary partitions.
Primary partitions are the only ones that OSes can be installed to (Windows, anyway).
Primary partitions are the only partitions the system can boot from
Each extended partition counts as a primary partition.
6 or 7 partitions may be needed.
TrueCrypt can’t encrypt an entire drive that has multiple partitions, OSes, and various file systems when it only runs on one
TrueCrypt doesn’t play well with Grub or any non-Windows boot loader.
Windows likes to be installed first and only on a partition flagged as “bootable” (or, if no partitions are flagged “bootable” at all)

Benefits in the end

After the initial boot loader prompt, mounting various encrypted partitions could be automated with scripts. (<3 Truecrypt)
Files can be shared between encrypted operating systems (with password).
Each and every partition is encrypted, even swap file.

How the boot loaders work together

We install and use Windows’ default boot loader to the MBR. This is what the computer will boot to first.
We install GRUB (Fedora’s boot loader), but not to the MBR. This will merely be available for us to boot to later.
We install TrueCrypt which takes over the Windows boot loader. TrueCrypt’s boot loader goes into the MBR. On boot, the user will authenticate with TrueCrypt then be taken to the Windows boot loader where the option Vista or Linux (actually GRUB) becomes available.
In the end, my boot process looked like this:

Diagram of full-disk encrypted dual-boot process (yellow boxes are encrypted partitions; padlocks are another layer of security)

Possible adjustments for your situation

I didn't use Truecrypt on the Linux side except to mount the Windows partitions. I'm not sure how to mount native Linux-encrypted partitions from Windows, so my setup was rather one-way. You might consider using Truecrypt to encrypt at least your Linux /home directory and let native Linux encryption protect the /swap partition, for example. This might allow Truecrypt on the Windows side to mount your Linux files.
Re-partition your hard drive in-place, or add another drive for Red Hat. The folks over at SuperUser probably know more about this.
Figure out how you're going to partition your hard drive ahead of time... you don't need as many partitions as I used.

Requirements

A computer with at least one hard disk you are willing to wipe clean (Back up your data first, of course...)
Installation discs of the OSes you wish to install
Gparted LiveCD or LiveUSB
TrueCrypt
EasyBCD to modify the Windows boot loader (There's a free version...)

Instructions

Back up your data. You are going to wipe the hard disk totally clean and reformat it very soon.

Reformat the entire drive. To do this, I use Gparted LiveCD. If you don’t want to use Gparted, Fedora 10’s installer comes with a partition editor. But, it’s a bit trickier. You’ll have to partially complete the Fedora setup in order to get to it, apply the changes to the disk, then exit setup because Fedora shouldn’t be installed first. (Windows Vista’s partition editor is NOT powerful enough. You cannot use it for this.) I strongly encourage the use of a Gparted LiveCD or LiveUSB.

I thought about how to split up my drive and after a while, I came up with this:

Partition layout for dual booting Fedora 10 and Windows Vista with TrueCrypt

I wish I had sized them differently in hindsight, but you can do it however you want. Each padlock indicates an encrypted partition. The yellow padlocks with “TC” are encrypted with TrueCrypt in Windows. The blue ones are encrypted by Fedora. As you can see, each and every partition - except, of course, the /boot partition - is encrypted. Partitions labeled in red are for Windows. Black is for Linux.

Okay, so this is a setup that works for me. Basically, you’ll want these things:

A primary boot partition to put Grub (the boot loader Fedora can install for you) - I recommend about 50 to 100 megabytes. Do not flag this as “bootable” when partitioning - Windows will complain.
An extended partition to hold all the “data” or “miscellaneous” partitions. This will hold your Fedora /home directory (basically the “My Documents” folder of Linux), Windows backup partition (optional), and your Linux swap file (highly recommended). The swap file should be at least as large as your RAM’s capacity.
A primary partition for Windows Vista to be installed to.
A primary partition for Fedora 10 to be installed to.

Partition your drive as such and be sure to format with the appropriate file systems. You can use the table above as reference.

Write down the sizes of your partitions (in order) and their filesystem. You'll need this during the OS installs.

Start installing Windows Vista. You’ll be forced to do a custom installation. Choose the primary NTFS partition you reserved for the Windows install. Don’t forget to load hard disk drivers - especially on laptops. If your Windows install hangs around 70%, then you need to install the SATA drivers for your laptop. Once drivers are loaded and you select the right partition, install Windows.

After Windows installs, boot into it normally and finish setup. Don’t spend too much time customizing things yet. Once it is running, shut down and insert the Fedora 10 DVD. Boot to that and install Fedora. However, take note of the following:

Be sure you choose to do a custom layout for your partitioning. Fedora will want to wipe things and create its preferred partition layout by default. Don’t let it do this. Make sure you go straight to the part where you can view and modify your current partition information.
Don’t format the NTFS partitions. Windows is on one of them.
Be sure to set the mount point for the small partition (100 MB?) to be /boot. -Check “Format as” and select “ext3.” You cannot encrypt this partition.
Set the mount point for the partition for your /home directory to… you guessed it: /home. Check “Format as ” and select “ext3″ then choose the “Encrypt” option.
Set the mount point for the partition for your swap file as /swap. Linux will have to format it and you should, of course, select “Encrypt.”
Set the mount point for the partition for your main Fedora install to be “/”. Check “Format as” and select “ext3″ then choose the “Encrypt” option.

Before continuing, ensure that neither of the NTFS partitions have a check mark next to them. If they do, they will be formatted and you’ll have to start over. Continue. Fedora will warn you it will delete all the data on the modified partitions. That’s okay. You may have to set your passwords now as well. Go ahead and do that.

Soon it will ask you about the boot loader. Tread carefully here. Do not write the GRUB boot loader to the MBR. When it says “Install the boot loader on/dev/sda1″ (the “sda1″ may be different) - keep the box checked but click “Change Device” and choose “first sector of boot partition” instead.

After that step, you should be home free. Finish up the install and reboot the computer. It will boot straight into Windows.

Once Windows loads, download and install EasyBCD. You’ll want it to easily modify the Windows boot loader. Add an entry to the boot loader: click “Add/Remove Entries” - choose the “Linux” tab, select “GRUB” from the dropdown, and name it something intelligent. Choose the partition that contains GRUB, not Fedora. Leave the checkbox unchecked.

Add the entry then try rebooting. You should now be able to boot into either Fedora or Windows! Boot into Windows again and encrypt it, as follows:

Install TrueCrypt and create a new volume. Choose “Encrypt the system partition or entire system drive.” From this point, you’ll have to choose the proper options. Read them carefully! I don’t remember the exact sequence, but you need to specify “Multi-boot” at some point. At the end it will ask whether Windows has its boot loader in the MBR or if a different boot loader is used (like GRUB). Remember: we're using the Windows’ boot loader (we want Truecrypt to "overtake" it).

Once you’ve finished the volume creation wizard, you’ll be asked to “Test” the system. It will restart for you. It should boot into the TrueCrypt boot loader where you’ll type your password. After that, it should load the Windows boot loader where you can boot into either Linux or Windows.

From here, finish encrypting the Windows system partition, then remember to encrypt any other NTFS partitions you made for Windows.

When you’re done, try booting into Linux. It should go to the GRUB boot menu where you can select Fedora or change your mind and go back to Windows. As Fedora boots, you’ll be asked for your password as it mounts the encrypted partitions.

Tl; dr (Too long; didn't read)

It took me a few tries to get it right with two OSes, and employed the use of software like EasyBCD, Truecrypt, and Gparted, but I was successful in the end... for 2 OSes. Good luck with 4. The key is to plan effectively. Size and format your partitions properly, then install operating systems in the correct order. (Usually Windows goes first.)

PS. Hm, For a simpler solution, though not quite what you asked for: have you considered running 3 of the 4 operating systems in virtual machines? You can encrypt the host machine, thus protecting the other 3 at the same time. (And if you're worried about losing the VHD files, remember you can fully encrypt the guest OSes, too.)


Router sends password plaintext: is this a serious vulnerability?

Router admin authentication is required to expose the password plaintext.

This is a bad design for certain.  It means the router is storing the ISP password in a reversible form.  However, it has to reverse it to authenticate to the ISP.  The real problem is that is unnecessary to expose.

This problem also exists on enterprise-level network gear.  On Cisco firewalls it is possible to expose IPsec shared secrets and other similar symmetric/password credentials by running commands that show the configuration details from a CLI.  This is done in part to support easily restorable backups of the config.

Exposing it in the user interface is unneccessary.  This is an example of a Sensitive Data Exposure vulnerability (OWASP Top 10 2013-A6).  It's considered to be hard to exploit (you need to be an admin on the router already), but high impact.   In this case the value of the ISP client network authentication credentials is unlikely to be particularly significant.  The ISP can have compensating controls in place and multiple authentications from separate locations would be an obvious violation that the ISP would notice.

I don't consider this to be a serious vulnerability.  It should be addressed, but I don't consider it a show stopper requiring a different router to be deployed.


Aren't VPN servers exposed to the same threats as public Wi-Fi?

You hit the nail.... "trust of the VPN provider"....

Whilst we can read what a VPN provider might offer, this still doesn't solidify the fact we have no real idea.

We have to just assume the VPN provider is routing our traffic in the correct manor and sourcing it from random locations as per our request. We also have to assume they encrypt log files (if they store them) and encrypt our traffic.

It's maybe too open ended to give a short & sweet answer here, but we can guarantee that certain VPN's don't use the best encryption methods, especially most of the free VPN's that only offer single layer protection (i.e, just concealing your IP and nothing else).

VPN servers are indeed vulnerable to mitm attacks, but the amount of variants that come into play are quiet large, the best summary of which would be to say it really does depend on the quality of services the VPN distributor is providing.


What's the purpose of the client nonce in SSL?

There is no "client nonce" in SSL/TLS. There are some "used only once" numbers created by the client, like the IV for the symmetric encryption or the "client random" for the TLS handshake. In the following I will assume that you mean client random instead.

Client random is for example used to build the message the server has to sign with the private key belonging to the server certificate as part of the initial server authentication. If client random would be repeated then some attacker might replay a previously captured reply of the server containing the appropriate signature and thus successfully claim to own the private key, i.e. authenticate as the server.


Basic Auth obviously could protect from ordinary internet users but it definitely will not protect from hackers, because such credentials are easily obtained from the app or its traffic. So you could ask about the threat model.
On the other hand your operations (dev) team got the additional unnecessary task (and potential point of failure) to support and update this shared secret.

Best practice here is to build a resilient architecture with strong actual authentication for Class B functions approved by industry.


cgroups and namespaces are about isolation whereas SELinux is a mandatory access control system: fine-grained access over which system calls are allowed, how information is allowed to flow between processes (domains).

The android permissions that applications have to subscribe to can be easily enforced through SELinux, as can process isolation and even many potential vulnerabilities can be mitigated through the SELinux policy (as long as the exploitation of the vulnerability is not contained within the application or is a kernel vulnerability).

cgroups and namespaces have a different function, and not necessarily an exclusive one: SELinux, cgroups and namespaces can happily be used together (improved SELinux support for namespaces is being worked on, but they can already be used together).


Will a DDOS attack prevent outbound traffic?

Answer (like a lot of answers in info sec): It depends.

If the DDoS attack is swamping the network infrastructure, it may be difficult for an outbound packet to make it through (even with higher priority) because the network switches and appliances might be too busy to process it. On top of this, if it is a TCP connection then it'll need the reply packets to return too before the connection can be established.

If there is another network interface with a route to the outside, then there may be more of a chance for the outbound connection to be established via this other route. This of course depends on how the server itself is holding up against the DDoS attack.


Is it possible for an open-source website be secure?

The database login credentials should not be part of your sourcecode. They should be part of the configuration files. The production version of these configuration files should not be part of the official codebase. You should only publish an example configuration with example parameters.

This is not just recommended from a security perspective, it also makes it much easier for others to use your project. They will definitely have other login credentials than you do, so providing a config file where they can enter them is much more comfortable than digging through the source and replacing all references to them.

For more information, check the question "Strategy for keeping secret info such as API keys out of source control?" on programmers stackexchange


What operating systems and devices are known to be affected by Shellshock? What patches are available?

Below are products for which vendor statements or reputable research has been found to confirm their vulnerability status. Additional information may also be available at the following sites:

US-CERT - The United States Computer Emergency Response Team

Alert (TA14-268A)
Vulnerability Note VU#252743

Shellshocker.net - Website dedicated to Shellshock vulnerabilities. Maintained by the Medical Informatics Engineering IT team.

DISCLAIMER: This is not by any means a comprehensive list of affected products, nor does it necessarily represent all of the information or patches that are currently available for the listed products.

Inclusion of information in this list simply means that someone has found Shellshock-relevant information and has cared to add it to the list. Omission of details does not necessarily mean that a product is not affected, or patches are not available.

If a product you use, is not listed below, and you are unsure of whether or not it is affected by Shellshock-related vulnerabilities, you should contact the product vendor yourself. You should also contact the vendor with your concerns if their product is listed, but status for one or more vulnerabilities is not. If the vendor provides links to publicly-accessible statements regarding how their products are affected and what remediation options are available, please add them to this list.

Last Update: 2014-09-30 00:30Z

Amazon Linux

Affected Versions:  (Unspecified)

CVE-2014-6271

Vendor confirmation & remediation instructions: ALAS-2014-418

CVE-2014-7169, CVE-2014-7186, CVE-2014-7187

Vendor confirmation & remediation instructions: ALAS-2014-419

CVE-2014-6277, CVE-2014-6278

No data (2014-09-29 23:30Z)

CentOS

Affected Versions:  5 through 7 (Per vendor notice. Earlier versions unconfirmed.)

CVE-2014-6271

Vendor confirmation & remediation instructions: [CentOS] Critical update for bash released today.

CVE-2014-7169, CVE-2014-7186, CVE-2014-6277

Vendor confirmation & remediation instructions: [CentOS] Critical update for bash released today.

CVE-2014-7187, CVE-2014-6278

No data (2014-09-29 23:30Z)

Cisco

Affected Products:  (Multiple - see advisories for details.)

CVE-2014-6271, CVE-2014-7169

List of affected & non-affected products, and remediation instructions: Cisco-SA-20140926-bash

CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278

No data (2014-09-29 23:30Z)

Debian

Affected Products: (Unspecified)

CVE-2014-6271

Vendor confirmation & remediation instructions: DSA-3032-1

CVE-2014-7169, CVE-2014-7186, CVE-2014-7187

Vendor confirmation & remediation instructions: DSA-3035-1

CVE-2014-6277

Vendor status page (patch status indeterminate as of 2014-09-30 00:00Z): CVE-2014-6277

CVE-2014-6278

Vendor status page (patch status indeterminate as of 2014-09-30 00:00Z): CVE-2014-6277

Gentoo

Affected Products: (Unspecified)

CVE-2014-6271

Vendor confirmation & remediation instructions: GLSA-201409-09

CVE-2014-7169

Vendor confirmation & remediation instructions: GLSA-201409-10

CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278

No data (2014-09-30 00:00Z)

Oracle Enterprise Linux

Affected Products: 4 through 7 (Per vendor notice. Earlier versions unconfirmed.)

CVE-2014-6271

Vendor confirmation & remediation instructions:

Oracle EL 4 - ELSA-2014-1294
Oracle EL 5 - ELSA-2014-1293
Oracle EL 6 - ELSA-2014-1293
Oracle EL 7 - ELSA-2014-1293

CVE-2014-7169

Vendor confirmation & remediation instructions:

Oracle EL 4 - ELSA-2014-3079
Oracle EL 5 - ELSA-2014-1306
Oracle EL 6 - ELSA-2014-1306
Oracle EL 7 - ELSA-2014-1306

CVE-2014-7187, CVE-2014-6277, CVE-2014-6278

No data (2014-09-30 00:30Z)

Ubuntu

Affected Versions:  10.04 through 14.04  (Per vendor notice. Earlier versions unconfirmed.)

CVE-2014-6271

Vendor confirmation & remediation instructions: USN-2362-1

CVE-2014-7169

Vendor confirmation & remediation instructions: USN-2363-2

CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278

No data (2014-09-30 00:30Z)


What does "probability space is over coin flips of algorithm M" mean?

I have contacted the authors and they were very helpful. The original quote says it all:

  The book is about randomized algorithms that act on data sets. You can always view these as deterministic algorithms, which take two inputs -- the data set, and also a string of random bits.

  The definition of differential privacy has a probability operator, and what that remark means is that the probability is taken over the randomness of the random bit string (i.e. the internal randomness of the algorithm), holding the data set fixed.

The key to this is that the definition says: "the algorithm ℳ outputs ... with probability ...". This is a random choice, and the source of randomness is defined by the sentence "The probability space is over the coin flips of the algorithm ℳ".


Is there any working solution against large SYN Flood request?

Cloudflare should terminate all connections and thus prevent these spoofed syns from arriving at your server. Appears to be a misconfiguration since this traffic is being seen at your server.

Per their documentation:

  How does Cloudflare mitigate SYN Flood attacks?

  Cloudflare mitigates this type of attack in part by standing between the targeted server and the SYN flood. When the initial SYN request is made, Cloudflare handles the handshake process in the cloud, withholding the connection with the targeted server until the TCP handshake is complete. This strategy takes the resource cost of maintaining the connections with the bogus SYN packets off the targeted server and places it on Cloudflare’s Anycast network. Learn more about how Cloudflare's DDoS Protection works.

  Source: Cloudflare - SYN Flood Attack

From the same source (Cloudflare - SYN Flood Attack), mitigation techniques include:

  Increasing Backlog queue

  Each operating system on a targeted device has a certain number of half-open connections that it will allow. One response to high volumes of SYN packets is to increase the maximum number of possible half-open connections the operating system will allow. In order to successfully increase the maximum backlog, the system must reserve additional memory resources to deal with all the new requests. If the system does not have enough memory to be able to handle the increased backlog queue size, system performance will be negatively impacted, but that still may be better than denial-of-service.

  Recycling the Oldest Half-Open TCP connection

  Another mitigation strategy involves overwriting the oldest half-open connection once the backlog has been filled. This strategy requires that the legitimate connections can be fully established in less time than the backlog can be filled with malicious SYN packets. This particular defense fails when the attack volume is increased, or if the backlog size is too small to be practical.

  SYN cookies

  This strategy involves the creation of a cookie by the server. In order to avoid the risk of dropping connections when the backlog has been filled, the server responds to each connection request with a SYN-ACK packet but then drops the SYN request from the backlog, removing the request from memory and leaving the port open and ready to make a new connection. If the connection is a legitimate request, and a final ACK packet is sent from the client machine back to the server, the server will then reconstruct (with some limitations) the SYN backlog queue entry. While this mitigation effort does lose some information about the TCP connection, it is better than allowing denial-of-service to occur to legitimate users as a result of an attack.


How to secure a web-only end to end encrypted chat with message persistence?

I am the developer of https://www.encryptedsend.com/, which is a browser-based end-to-end encrypted messaging system with message persistency.  Encrypted messages are stored on the server, as you describe in your question.
With regard to your question,

My main problem right now is, that I'd somehow have to persist the
chat key for the customer, but I don't know how

There are a number of ways to handle key management in in-browser crypto applications:
One solution is to simply derive a key from a password that the user enters when the he/she begins a session with the application.  Then, the key is derived from the password (via client-side scripting, in-browser) using a key derivation function such as PBKDF2, with a large number of iterations.  This solution is simple to implement, and has the advantage of not requiring any storage on the client side, and does not create challenges if users need to access the system from multiple devices, but may be susceptible to brute-force attacks if weak passwords are used.
Another solution is to use IndexedDB to store users' private keys.  See more information about this solution here.  This solution is more resilient to brute-force attacks than the above solution (because the key is not derived from a password), but the private key is stored unencrypted in IndexedDB (see here), and this solution may present challenges if the user wants to access the system from multiple devices, as this would require keys to be transferred from IndexedDB on one device to IndexedDB on another device.
Yet another solution is to store the private key in a file, which the users is responsible for storing securely on his/her system.  For additional security, this file is encrypted using symmetric encryption, with a key derived from a passphrase via PBKDF2 with a large number of iterations.  When the user begins a session with the application, he/she provides the key file to the browser, along the password to decrypt the file, and client-side in-browser scripting decrypts the file to access the private key.  This private key never leaves the web browser, and is then used to authenticate the user with the server, and to decrypt encrypted messages downloaded from the server.  This solution is resilient to brute-force attacks (because the underlying key is generated randomly, instead of from a password), it does not store the key unencrypted on the user's system, and the user can access the system from multiple devices by (securely) transferring the file to each device.  This is the method used in EncryptedSend.  For more information, see the whitepaper.


Can a website make an HTTP request to "localhost"? How does it get around the cross-domain policy?

Im surprised nobody has pointed out that the accepted answer (by meltdownmonk) is wrong.

  "It will not break cross domain policy, because the request will not
  cross domains.  It will stay local. One way to avoid cross domain
  policies, is to get the target victim to make the HTTP request
  themselves. Thus the request never crosses domains."

  "It's not the website itself connecting to your Redis machine. It's
  you connecting to your Redis machine, executing client side
  code/scripts that you ran by clicking the link"

  "The attacker doesn't have full control over the process. They rely on
  the owner of the Redis server to execute the code."

  "...it's not the attacker that executes them, it's the owner, and so no Cross Domain Policies are violated."

This is not how the Same-Origin-Policy (SOP) and Cross Origin Resource Sharing (CORS) work. Of course the request will cross domains when a website tries to connect to localhost. Also it is the website itself trying to connect to your redis
and not the user - the attacker does not have to rely on the user. There is no difference whether the code runs automatically in the background or if the user clicks a button.

A website is basically able to send requests to localhost on different ports and can thereby even run a port scan. The browser's CORS implementation will ensure that data cannot be read by javascript. Therefore, the attacker cannot steal data from localhost and send it to a server. This is only true of course as long as your services on localhost do not explicitly allow CORS requests to be made (when they sent allow-origin headers, the attacker can steal data).

Apart from this, requests are still possible and therefore CSRF attacks are also possible. Such a CSRF attack could be triggered with a simple javascript HTTP-request (which does not require a CORS preflight check), but also HTML form data sent via GET/POST and websockets can be used to establish a connection to local services.

So to sum it up, if you visit a website, this website will be able to send requests to your local services on your computer on different ports. Reading data from your local services is normally not possible.


Secure key generation and authentication in PHP

The question is more geared towards is it a good idea to generate
  passwords for the users and email it to them?

Reasons not to do this include:

It could be vulnerable to shoulder surfing. A user walking past while another user opens their email not expecting a password to be displayed could have their credentials stolen. This is particularly a risk at a college environment where everyone is using the same system.
This violates a policy of never outputting passwords. A more secure system only ever has passwords input - stick to this rule and you will tend to find you generally end up with a fairly secure system in terms of password management.
Anyone who has temporary access to an email account will be able to grab the password undetected. For example if the workstation is left unlocked for a very short period it will enable a very passive attack where very little evidence of the compromise remains.

A more secure system would email and instead include an link and a cryptographically secure one time code. This will enable the student to follow the link, enter the code (the link and code can be combined with the query string, however this is slightly less secure as URLs are logged by default, stored in history and can be exposed in the referer header) and then set up their own password.

Once the password has been setup, the link cannot be used again, making any later use of the email benign.


Multiple passwords, same account, different privileges

The inherent problem is that the computers are untrusted - multiple passwords going through the same untrusted channel won't really help, and may confuse your clients more than help them.

I would strongly suggest adding a second factor authentication via a trusted channel like your client's smart phone. 2FA does not have to be onerous or complicated.

Begin by making the feature optional, but advertise and recommend it to your customers. Collect feedback and audit whether clients who enable 2FA ever get their credentials compromised.


How to encrypt files on my SD card and still be able to access them on my phone seamlessly?

I don't think there is any method of encrypting an SD card's contents that would make that SD card viewable on an out-of-the-box Android and Windows installation.

Android doesn't officially support any encryption method on SD cards, but some manufacturers have built in their own encryption scheme for file-based encryption on SD cards.  Encrypting your SD card contents such a scheme will render it unreadable on Windows, however.  Also, it will probably also be unreadable even on another phone of the same model due to the key being tied to the phone.

Windows supports encryption in NTFS in some circumstances but an Android phone won't be able to read that.


Is it recommended to send an authentication request to the Resource Owner (by the Authorization Server) if it already has an active session?

Actually you won't know from the client side whether the resource owner has an active web session on the authorization server or not, and it's not the client's matter.

That's however up to the authorization to decide what to do, for instance:

Authenticate if the resource owner is not logged in
Grant immediate access without logging in again if the resource owner has already logged in, or reauthenticate him (for instance if he logged in more than 7 days ago) by killing or updating the session. Reauthentication can also consist in requiring a second factor (SMS OTP...)
Make the resource owner authorize some scopes he has not approved yet
Or even ask him to approve new CGUs
Etc

In a nutshell, it's the authorization server's matter to decide what to do (i.e. applying an authentication and authorization policy), not the client's.

If the resource owner is already logged in, has approved the requested scope, etc. then the server will redirect to the client directly with an authorization code. In this case a blank page will shortly appear, the URL will change swiftly (redirects) before the resource owner is redirected to the client. This is how SSO (Single Sign-On) works.


The reason of using XOR operation in cryptographic algorithms

XOR is an operation that can always be reversed, all information is retained.  It is as simple as that.  Using AND and OR may result into information loss because you cannot tell if certain bits were either 1 or 0 in the operands.

Playing a little with the python repl, we will use 19 (10011) and 5 (101) since these numbers make for good examples.

Using OR you lose the information about which of the operands had a certain bit on:

>>> bin(19|5)
'0b10111'

Isn't that 19?  Yep, that's 19.  The resulting number cannot tell us that it has been ORed with 5.

Using AND is the same:

>>> bin(19&5)
'0b1'

That's 1.  There is not way for us to recover neither number (19 or 5) easily, we lost information again.

XOR is good for cryptographical tools because you do not lose information when XORing:

>>> bin(19^5)
'0b10110'

That's 22.  Apparently that does not tell us much, but see this:

>>> bin(22^5)
'0b10011'
>>> bin(22^19)
'0b101'

You can recover either number by XORing the 22 with the other number.  That's a very primitive conception of a secret key.  Assuming that you and someone else can have a huge list of very big and random numbers (both of you have the same numbers), you can simply XOR messages and then securely exchange between yourselves.  As long as you guys use a different number every time you communicate that is a secure algorithm.  The algorithm is called an one-time pad.


What information will dig leak to an attacker?

AXFR is the traditional way of zone transferring - you just completely copy the dns records from one zone to the other - an attacker will have a complete list of resources in the organizations and if you save some more information on those servers on your nameserver it will be included

IXFR on the other hand helps sysadmins in replicating an already given zone that was doing a complete AXFR in the past and need to be updated to the latest record revision on the nameserver, without the hassle and band-choking of a complete copy of records.
in IXFR you can select the revision that you have and the server will provide you with the updated data since your revision, to an attacker is the same as before - just less information.


Can heuristic analysis detect keylogging?

Most systems provide APIs and hooks that allow apps to capture keystrokes (for instance for keyboard shortcuts)

A heuristic could detect the use of such facilities and flag the app for further analysis or provide means to whitelist/block the app, similar to those firewall prompts on Windows.

Modern keyloggers seem to also log the clipboard, presumably to account for paasword manager users.

As all heuristic analysis, it's subject to being subverted/bypassed by a creative keylogger developer.

The logging can also be subverted by tools like KeePass that adds bogus keystrokes when inputting passwords to confuse keylogger.

This rapidly leads to an arms race of increasing costs for both sides :)


Background. First off, I want to share with you some background about browser add-ins.  There are two kinds of add-ins: extensions and plug-ins.

An extension is a Javascript-based add-on that gains partial access to your browser, but is (at least in Chrome) restricted by a browser sandbox.
A plug-in involves native executable code that gains much more intimate access to your browser, and is not restricted by any sandbox.  For instance, Flash player is a plug-in.

Plug-ins are considerably more dangerous, because they have full access to your filesystem, full access to run programs on your machine, full access to your browser (and all web sites you visit, passwords, etc.); they can do anything you can do.  Extensions are more limited in what they can do (at least in Chrome), and thus (in Chrome) are safer.

I suspect you are asking about an extension, not a plug-in.  For instance, the extensions in the Chrome Gallery are extensions.

How to tell if it is safe.  In general, there is no good way to tell if an extension is safe.  You can look at reviews from other users (though this is not fully dispositive).  You can look to see if the extension has been around for a while, has a significant number of users, and/or comes from a respected brand/company/developer (though this is only an indicator and certainly not a guarantee of security).

And, perhaps most importantly, in Chrome you can look at the permissions that the extension is requesting.  This will tell you what information the extension will gain access to and what it could do, if it were malicious.  A malicious extension will be constrained by its permissions, so the fewer the permissions, the lower the risk of the extension.

Further reading. For more information, I suggest that you read the following:

What are the security implications of people downloading plugins, wrongly thinking that they are safe?
How can I assess the trust worthiness of a browser add-on?.


How can I implement authentication in my proxy server?

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication.
This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience).
If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)


Is there a reason to use TrueCrypt over VeraCrypt?

I would still choose TrueCrypt for a matter of trust and the "many eyes" theory:

After the "TrueCrypt scandal" everyone started looking at the source for backdoors.
The TrueCrypt audit finished on April 2, 2015. They found low-risk vulnerabilities, including some that affect the bootloader full-disk-encryption feature, though there is no evidence of backdoors.
If VeraCrypt start changing TrueCrypt fast, they may introduce a few vulnerabilities. Since VeraCrypt is currently less popular than TrueCrypt, there are 'less eyes' watching at the VeraCrypt source code changes.
I consider that TrueCrypt 7.1a have all the features I need. An audited TrueCrypt with the vulnerabilities fixed would be the perfect choice. Unless I personally watch VeraCrypt source code diffs, it would require an audit on the changes, or a high increase in popularity, or many years of maintenance and active community to make me trust them more than the good old TrueCrypt.
The increase in iterations to mitigate brute force attacks only affects performance. If you chose a 64-char random password, 1 million years of brute forcing or 10 million years is the same from a security stand point.

(I downloaded the public key of TrueCrypt admin years before the scandal. So I can download a copy of TrueCrypt 7.1a from any source and verify its authenticity)

This answer may change after they publish new results from the audit. Also, if you are the VeraCrypt dev, the trust argument doesn't apply (because you trust yourself).


Extracting Individual Records from NTDS.DIT

Here is one method, and the bonus is that it is all done remotely -- https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/

The author also shows how to dump the whole thing, but of course this isn't recommended. You could also copy the dit file locally, split(1) it, and then exfiltrate the files piece by piece.


Yes, it's possible, but it's a lot harder than you think, and you'll end up breaking some things no matter what.  To take your full-screen video example, it's not the website that asks for the screen size, it's Javascript running on a web page, and you can't know at the time of the request if it's going to use the size to adjust a video, or to fingerprint the browser.

The Tor browser bundle attempts to do this with reasonable success.  I recommend studying it to see how it works, and how it can be improved upon.


Due to the use of the Diffie-Hellman key exchange, knowing the server's private key does not help a passive-only attacker. If the attacker wants to learn the data, then he must go active.

If the attacker knows the server private key, then he can impersonate the server, i.e. run a fake server and let users connect to it. For a full Man-in-the-Middle attack, the attacker must do a double impersonation: as a fake server when talking to the genuine client, and as a fake client when talking to the genuine server. If the server uses password-based authentication, then this is easy: the client will send his password to the fake server, at which point the attacker knows it and uses it. If the server expects a key-based authentication from the client, this won't work.

However, chances are that a fake server (non-MitM) can fool a client and learn secrets without going full MitM.


How to deal with tunnel applications such as TeamViewer on the corporate network

The most common solution I see is to have the firewalls at each location set up to only allow the tunnel to connect to specified endpoints. This means it can still be used for the purposes intended, but can't be used to access other locations.

A pre-requisite is that you maintain centralised control over firewalls and endpoints, so there is no way to avoid access control.


Producing secure hashes to detect data manipulation

There are algorithms available that provide tamper protection. AES-GCM is one such algorithm. Per https://en.wikipedia.org/wiki/Galois/Counter_Mode

  GCM is an authenticated encryption algorithm designed to provide both data authenticity (integrity) and confidentiality.

AES-GCM is available on Android API 26+. https://developer.android.com/reference/javax/crypto/Cipher.html I recommend using an algorithm that already has authenticity checking built into it over trying to implement this sort of thing on your own.


How SSL/TLS handshake happens when we use Cloudflare Service?

You would need to provide your private key to Cloud Flare to have them create a valid SSL/TLS connection with your clients on your behalf.  This gives them full plain text access to all content exchanged between your clients and you. This is one of the tradeoffs of using them.


The Airport model is a concept where the network infrastructure is split up to different zones secured with different levels of security that share information between the zones. Airport security is very similar and thus the name.

Just like in an Airport there is a "control tower" that is in charge of detecting any anomalies or incidents in the network. This "control tower" is usually placed in the SOC(Security Operations Center) team or under the CERT(Computer Emergency Response Team).

You can view a diagram of the model here in page 2 paragraph 1.2.


How valuable is secrecy of an algorithm?

Much of the work on passwords and keys is related to controlling where they are stored and copied.

A password is stored in the mind of a human user. It is entered on a keyboard (or equivalent) and goes through the registers of a CPU and the RAM of the computer, while it is processed. Unless some awful blunder is done, the password never reaches a permanent storage area like a hard disk.
An algorithm exists as source code somewhere, on the machine of a developer, a source versioning system, and backups. There are design documents, which have been shown to various people (e.g. those who decide whether to fund the development of the system or not), and often neglectfully deposited on an anonymous shelf of in some layer of crust on the typical desktop. More importantly, the algorithm also exists as some executable file on the deployed system itself; binary is not as readable as source code but reverse engineering works nevertheless.

Therefore we cannot reasonably consider that the algorithm is secret, or at least as secret as the password (or the key).

Really, cryptographic methods were split one century ago into the algorithm and the key precisely because of that: in a functioning system, part of the method necessarily leaks traces everywhere. Having a key means concentrating the secrecy in the other half, the part which we can keep secret.

"Security through obscurity" is an expression which uses the term obscurity, not secrecy. Cryptography is about achieving security through secrecy. That's the whole difference: a password can be secret; an algorithm is, at best, obscure. Obscurity is dispelled as soon as some smart guy thinks about bringing a metaphorical lantern. Secrecy is more like a steel safe: to break through it, you need more powerful tools.

Smart guy Auguste Kerckhoffs already wrote it more than a century ago. Despite the invention of the computer and all of today's technology, his findings still apply. It took a while for practitioners of cryptography to learn that lesson; 60 years later, Germans were still putting a great deal in the "secrecy" of the design of the Enigma machine. Note that when Germans put the 4-rotor Navy Enigma into use, Allied cryptographers were inconvenienced (routine cracking stopped for a few months) but were not totally baffled because some captured documents from the preceding year alluded to the development of the new version, with a fourth "reflector" rotor. There you have it: algorithm secrecy could not be achieved in practice.

An additional twist is that algorithm obscurity can harm security. What I explain above is that obscurity cannot be trusted for security: it might increase security, but not by much (and you cannot really know "how much"). It turns out that it can also decrease security. The problem is the following: it is very hard to make a secure cryptographic algorithm. The only known method is to publish the algorithm and wait for the collective wisdom of cryptographers around the world to gnaw at it and reach a conclusion which can be expressed as either "can be broken that way" or "apparently robust". An algorithm is declared "good" only if it resisted the onslaught of dozens or hundreds of competent cryptographers for at least three or four years.

Internet, academic procrastination and human hubris are such that, with the right communications campaign, you can get these few hundreds of cryptographers to do that hard assessing job for free -- provided that you make the algorithm public (and "attractive" in some way). If you want to maintain the algorithm obscure, then you cannot benefit from such free consulting. Instead, you have to pay. Twenty good cryptographers for, say, two years of effort: we are talking about millions of dollars, here. Nobody does that, that's way too expensive. Correspondingly, obscure algorithms are invariably much less stress-tested than public algorithms, and therefore less secure.

(Note the fine print: security is not only about not being broken, but also about having some a priori knowledge that breaches won't happen. I want to be able to sleep at night.)

Summary:

You should not keep your algorithm secret.
You do not know how much your algorithm is secret.
You cannot keep your algorithm secret.
But you can and must keep your password secret, and you can know "how much" secret it is (that's all the "entropy" business).


sqlmap cannot find a dispatched vulnerability

This appears to be some type of what is known as Second Order SQL Injection.

Even if Thread 1 writes to a queue instead of to a DB, as the injection does not happen as a direct result of it, sqlmap cannot be used to exploit the vulnerability.

Sqlmap looks for error messages in responses or differences in timing (for blind SQL injection) to determine whether a page is vulnerable. Since these types of attack will usually be undetectable using these methods (unless it does alter the original page - but then you've got a latency issue), sqlmap would not be able to exploit it.


Taking your question at face value:

  Compare a 15-1-characters password with a 7-words/35-characters passphrase.

Before we can make a meaningful comparison, we need to start with some assumptions.

Can either password be broken with an intelligent algorithm outside of brute force? (More details on this can be found here.) If the answer is no, then obviously a 35 character password is much stronger than a 15 character password. Let's assume the attacker has considered the scenario that your password could contain a passphrase.
Although there are hundreds of thousands of words in the English language, we (probably) only need to try brute-forcing passphrases using the set of the most common words. We'll assume there are 3000 words in that set.
The passphrase will use words that do not necessarily form a grammatically correct sentence. (e.g. correct horse battery staple)
The non passphrase password has the same entropy as a random password and therefore cannot be cracked outside of brute force. (For now, we're ignoring the possible algorithm presented for generating it.)
The password character space is 80 characters. (Obviously this can vary but we need to start somewhere.)

So, some quick math here and we have:

15 char password: 80^15 = 3.5 * 10^28
7 word passphrase: 3000^7 = 2.2 * 10^24

By this calculation a 15 char random password is slightly stronger than a 7 common word passphrase. (A 13 char random password would be about the same strength.)

Notice that assumption #4 is pretty weak, as the first letter algorithm is likely not even close to having the same entropy as a random password, (because you will use less special characters, words have a different distribution of starting letters, etc). Therefore, I think it is easy to conclude a 7 word passphrase is significantly stronger than a 15 character password derived using the method you described, and even more so if at least one of the words in your passphrase is uncommon.


Do AppArmor/SELinux provide any security for workstation?

I did. You need a plan, and you need to master the tools. You need to be able to compromise where you can and where you have to compromise. You need to work to make it reality.

Access control is part of the bigger picture. There is trust involved inevitably. Knowledge about your environment and threats. Trade-offs. Common sense, a healthy dose of paranoia. Basically awareness in general.

But on a more practical note. It starts by only installing what you need. The more you have the more that can break. So you do not have to target every process imaginable. You target what you have to target to get the job done.

This is the security policy that i currently use. It is tailored to my environment and to my requirements. It has trade-offs, compromises. Because without that it would'nt be possible. Security is never absolute, but you can make the best of it, and that should be the goal.

Need inspiration?

This is DSSP my personal SELinux security policy:

https://github.com/DefenSec/dssp


Absolutely.

One way to go would be with ARP spoofing. It can be used to put your node as a gateway for the network.


What benefit to use different encryption key (passphrase) for different customers?

I highly suggest creating secure, random cryptographic keys every time you have to encrypt customer information via AES and enter it into the database.  Obviously, you will have to somehow store the keys since they will be randomly generated.  With that being said, I would suggest using a Hardware Security Module to store keys, but you should definitely check out this answer for more storage solutions.  Just make sure the data is encrypted and decrypted on the client's machine.

The benefit: Let's say an attacker compromised your customer database.  If he finds the encryption key, he has all of your customer's data, the encryption is rendered completely useless.  However, if the keys are randomly generated and stored in a Hardware Security Module, the attacker would basically have a useless database (unless he were to somehow get they keys from the HSM, which he shouldn't be able to do).  Your customer's security is an extremely important factor, and you should make sure you are doing everything you can to keep their information safe.


This looks pretty good. I can't see any glaring holes, except for the fact that SSL (https only) is switched off - though you mentioned that it'll be switched on in production.

You may also want to look into HTTP Strict Transport Security (HSTS) and Content Security Policy (CSP) (details / intro) for increased security.


Could my computer have downloaded some sort of virus or malware after clicking this button?

Short answer yes it could (doesn't mean it did).  I haven't taken the time to investigate the webpage or the button etc but as it apparently did what it said it would do on the page I wouldn't be too worried.

To learn more you could use a clean virtual machine (that is fully patched) and go poke around and see what it tries to do.  If you don't want to do that at least run a virus scan.


WAF - How to tell what automated tool is causing alerts

One reasonable starting point might be checking what the User-Agent is for the requests you are concerned about.
I would expect it to be forged, but it may be forged in a way that is still identifiable.

You could also consider profiling a few likely culprits (I would expect at least some tools to have a predictable sequence of attacks), by running them against a test instance of your WAF, and collecting the logs and alerts.

I am not completely sure, though, that you want to be worrying about which script is doing what, so much as what the actual attacks are (and which ones are relevant to you).
Although I can totally see how that would be an interesting thing to know.


Why do I need a valid /etc/resolv.conf if the DNS query is supposed to be sent over the vpn client?

The /etc/resolv.conf is the configuration for the resolver libraries which DNS server should be used. Even if you are using a VPN you still need a DNS server. Only, the communication with the given DNS server should be done through the VPN then.

For example if you use 8.8.8.8 as the DNS server then you should see the DNS query passing through your VPN interface (tun0 in your case) - which you also see there according to your question:

tcpdump -i tun0 -vv "host 8.8.8.8"
10.8.8.7.39209 > google-public-dns-a.google.com.domain: [udp sum ok] 17379+ PTR? ...

If you instead would use a DNS server in the local network (like 172.17.0.1) then the DNS query would not go through the VPN interface since the route to the local network is not set through the VPN interface (check netstat -rn or ip route for details). You would instead see the query pass through another interface (possibly eth0, depending on your exact setup). In this case you would have a DNS leak since the DNS query is bypassing the VPN.


EACCES on Android means you don't have sufficient privileges to access whatever medium (internal storage or external storage)you are trying to access.This may arise even when you don't declare the right permissions in manifest file.


How to find CAPEC items related to a CVE

The CAPEC schema contains a field - RelatedWeaknessesType or Related Weaknesses (version 3.0) which references one or more CWE ids related to the specific CAPEC entry. From this appropriate mappings to the according CVEs can be established. For example, CVE-2017-7269 is classified under CWE 119, which in turn is related to CAPEC 100.


Is the option to jump to blanks in password fields a security risk?

No that is not a security risk.

Having stored passwords in a browser is a security risk.  Letting an attacker access your computer between when you've typed in the password and before it is submitted is a security risk (and even after you've submitted it, you need to worry about theft of valid session cookies).  Being able to jump to blanks/special characters in a typed in password is not a risk.

After a password has been typed in the password field, its in the browsers DOM and only takes the least bit of effort to extract the full value out from it.  E.g., if you go to the developer's javascript console (e.g., in chrome/linux type Ctrl-Shift-J) and type in (you can skip the comment lines that begin with //):

var inputs = document.getElementsByTagName('input');
// find all <input> elements in the page

for ( var i = 0; i < inputs.length; i++) {
// loop through all <input> elements

    if (inputs[i].getAttribute('type') === 'password') {
    // find input elements with attribute type="password"

        console.log(inputs[i].value);
        // print the values of these password elements to the screen.
    }
}

It will print to the screen whatever text is typed into any password fields.  (This code is equivalent to the jQuery $('input[type=password]').value, which will work if the webpage has loaded jQuery).

You could just type the word javascript: in the location bar and then paste

var inputs=document.getElementsByTagName('input'); for( var i=0; i < inputs.length; i++ ) { if (inputs[i].getAttribute('type') === 'password') alert(inputs[i].value) }

into the location bar and whatever text is in any password field will be alerted to you.  (Note most browsers will remove the javascript: part if you try to paste the full URL, so you will have to type it.

javascript:var inputs=document.getElementsByTagName('input'); for( var i=0; i < inputs.length; i++ ) { if (inputs[i].getAttribute('type') === 'password') alert(inputs[i].value) }


First of all, I feel you are quite a mysterious person because no one could pretend to break 4096-bit RSA in the foreseeable future so I wonder why you need such a very long key.

Coming back to your questions now:

  But in which operation is this the case? Generating the keys?
  Encryption? Decryption? Signing? Verifying? All of them?

RSA keys are used in GnuPG for 2 reasons only:

To sign communications
To encrypt files.

  Can I expect problems with other PGP implementations with 8192-bit RSA
  keys?

The answer is Yes in case:

The destination person won't be  to decrypt messages with standard secure memory limits he/she has already set by default unless if he modifies that default setting.
The destination person does not have a hardware as good as yours since there is lot hardware not supporting  anything bigger than 2048 bits (there are even platforms that do not handle the memory locking mechanism used to generate RSA keys)


When distributing a CRL over HTTP, what is the optimal refresh time? What logic affects this decision?

I'm afraid the answer will be "it depends". How many simultaneous requests can your server(s) handle? How important is it to your organization that  information about a revoked certificate be propagated quickly?

If you put the Max-age setting too high, a revoked certificate will still be able to connect for up to the max-age setting. If you put it too low, you risk having too many clients connecting at once, bringing your CRL servers to a halt. Which of these factors is the most important one depends on the priorities of your organization.

If you e.g. have a requirement for a certificate revocation to propagate within 5 minutes, you need to make sure that your CRL servers can handle the load of every single client sending a request every 5 minutes - which means stress-testing the server with maybe thrice that load to be sure that it will be able to handle unusual circumstances. If your servers can't handle that load, you will need to either increase computer power, or accept that you can't propagate the CRLs that fast.


Best way to store a password in a text file

You want a password vault or password management solution that allows for application passwords, such as CyberArk Vault:

https://www.cyberark.com/solutions/by-project/application-credential-security/

Then your application calls the vault API to securely retrieve passwords from the vault.


Why is there not a SameOrigin flag that you can put on cookies to prevent CSRF?

It is a good idea, and as @paj28 pointed out in the comments, there is already an RFC draft for SameSite cookies.
One downside that is mentioned in the draft:

Consider the scenario in which a user reads their email at MegaCorp Inc's webmail provider "https://example.com/".  They might expect that clicking on an emailed link to "https://projects.com/secret/project" would show them the secret project that they're authorized to see, but if "projects.com" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.

Basically, a strict SameOrigin cookie would break links to backend components.
The draft also proposes a lenient mode which would send cookies on GET requests across sites, but it is a common problem that many applications do not follow restful, but instead have GET requests that change server state.
Another problem is that applications will still need to implement their own CSRF protection for all those users not using up-to-date cookies, so the extra development costs of correctly configuring SameOrigin cookies may not be worth it for some developers.


Since GET /c98efc0d-5c3f-45ec-996a-2cb82d35ed26.html HTTP/1.1 returns a 400 Forbidden, but an href link before the header, you should follow those hyperlinks.

You are on the right way by using CURL or similar instead of a normal browser as a normal browser would show a 400 Forbidden screen but not the link that was sent to it before.

Just write a small script that will follow those requests while there is a link in the response.
If you post the actual link of the CTF we might be able to give more specific answers.


Here's sample code for run-time process injection on linux. This is how meterpreter does it.LibHiJack


It doesn't really prevent you from getting the image. It just makes it take more work. You could take several screenshots or a video and get all the clear pieces from the separate frames/pictures and stitch them back together.


How to find out Wi-Fi password with dictionary attack without connecting to the Wi-Fi?

I am testing the security of WI-Fi networks which are not mine

I will assume you are acting in good faith and that this was passed by some ethical committee at your university. If not, I urge you to cease doing this and wipe any cracked passwords immediately, until you have such consent.

  Is there any possibility how to find out Wi-Fi password with dictionary attack without connecting to the Wi-Fi?

Sure. You're doing a bachelor's thesis in IT I assume? In that case, I'd say you should know this... but anyway, to answer the question, WPA2 does a handshake. If you capture the handshake, you can use it to brute force the password offline. This is also much faster than the online attack you are doing. The only requirement, since you need that handshake, is that you capture someone connecting to the WiFi network.

If I remember correctly, you need someone who successfully connects, but I might be wrong (i.e. you might be able to try to connect yourself with a password that you are sure will not work, and then use that handshake to brute force).

For the sake of completeness, in order to obtain such handshakes, you could do a deauthentication attack. Clients will automatically reconnect and you will get a positive handshake. I would however recommend that you do not do this, because it disturbs legitimate users (ethically wrong) and it's also illegal in any jurisdiction I know of (it's not jamming a signal exactly, but I'm reasonably sure I read about a conviction because it's close enough to be considered jamming).

  I am using android app WIBR+ which simply tests all words from my own dictionary one by one, but if it finds the password, it should also connect to the Wi-Fi.

Which is illegal, by the way. The Dutch law states one may not break into an automated system in such a way (it's even a felony if I remember correctly, not a misdemeanor or infraction), and I'm sure your country has similar laws.

Cracking the password is one thing; then using it to break into an automated system... that's where it becomes 100% sure to be illegal. But you seek to prevent doing that, which is good.

If the tool is open source, you could modify it to not include the connection part. And if it's not, you could patch the bytecode if you have the skills.

But since online attacks are slow, I don't see why you want to do this sort of attack anyway. It'd give much better (more reliable) results if you can do the cracking offline, and by doing it offline, you don't risk connecting to the network either.

Tools to do this are available in Aircrack-ng. Please use them responsibly; I believe I've given ample warning about the legality of your actions by now.

Edit: I missed this part:

  find out who is the owner of the Wi-Fi by the signal strength and ask him if i can check his Wi-Fi for this vulnerability

Ah, so you ask the owner for permission. That's good! Now I understand what you are doing a lot better. In that case, I'd not be afraid of joining the network: you have permission and you will disconnect immediately anyway, so what does it matter that it connects?


mobile number authorization strategy using SMS, best pattern and practices

Lets look at some different attacks and how they impact the two different systems, followed by some usability considerations.

Control of phone (draw)

If the attacker has full controll over the phone, it is game over no matter what. However, an attacker may have been able to get a trojan onto ther phone that only has limited permissions. At least on Android, reading and sending SMS is different permissions. However, this secnario feels rather contrived and I see no reason why it would be harder to get one permission than is is to get the other.

Social engineering (#1 wins)

To fool some users to read the code is easy if that is all the message contains. Call the user, say that you are from the cell phone company testing the reception or whatever, and that they will soon recieve a message to read back. (A competent attacker could come up with a way better lie than I just did.)

However, this can be made hard if the SMS contains an explanation of what the code is (and perhaps an exlpicit warning against phising), thereby revealing all your social engineering lies.

A user that has to send an SMS can get not such warning. That user could fall for tricks like "just send this code to this number to claim your free sport car". Not everybody would fall for this, but some would, especially if it is for a service they seldom use so they do not recognice the number.

Eavesdropping on the phone network (#2 wins)

As GSM encryption is famously weak, and fake cell phone towers to use for MitM can be bought on the internet, an attacker might try to eavesdropp on the SMS communication. This is not a theoretical threat, but something that is done in the wild.

With system one, an eavesdropper has to read the passcode that is sent to the user when they try to login. The attacker then needs to use it before the user (should be easy if the process is automated). This requires the attacker to be in the physical proximity of the target when the user happens to login to the service.

With system two, it doesn't matter if the attacker reads the SMS. The passcode is (or at least should be) unique to the users device, and the attacker can not authenticate on his device even if he knows the passcode the user sent.

SMS spoofing (#1 wins, major issue)

SMS spoofing is a very real thing that is used in the wild. If the attacker can spoof the users phone number in an SMS, he can overcome alternative two. This is a major weakness in that approach.

I just googled "free SMS spoofing service" and came up with this site. Surely even your computer illierate uncle could do the same, thereby bypassing your authentication scheme.

Usability (#1 wins)

Alternative two has some downside when it comes to usability:

The user has to enter a passcode and a number to send it to. This takes longer time. Two things to copy paste is twice as many as one.
The user might enter the wrong phone number, resulting in a failed login. If the wrong passcode is entered in alternative one, it is easy to give appropriate feedback to the user. If an incorrect phone number is entered, it is hard for the server to know what happend and give the right feedback to the user.
Sending a SMS might cost money for the user.

Conclusion

On security, it is 2-1 to alternative one. But how serious are the different vulnerabilities? I would argue that especially SMS spoofing but also social engineering are larger threats than eavesdropping. They can both be done from anywhere in the world, and require much less effort and technical knowledge. SMS spoofing could possibly be done automated on a large scale.

So even leaving usability to the side, I would argue that alternative one is the safer alternative.

TL;DR

You can spoof the sender of an SMS, making them useless for identifying the sender. Use the first alternative.


Issues with the use of network surveillance tool in your company?

If you are thinking of monitoring the network traffic of your own employees:

The most important thing you can do is warn your users that their communications are subject to monitoring by the company at any time, and they should have no expectation of privacy in their communications.

If you are thinking of building surveillance capabilities into your networks:

One security risk is that the surveillance capability provides a way for attackers to eavesdrop on traffic without authorization.  I know that surveillance capability is only intended for use by law enforcement, but building it into your systems introduces the risk that it could be misused.

For an eye-opening example of this risk, I encourage you to read up on the Greek wiretapping case in 2004-2005, around the time of the Olympic Games in Athens.  In 2005 it was discovered that the Greek telecommunication carrier's surveillance systems had been compromised and were under the control of unknown external agencies, who used the surveillance capability to wiretap over 100 cell phones belonging to key government officials: the prime minister, minister of defense, minister of foreign affairs, members of parliament, and so on.  The wiretapping capability had been build only for use by Greek law enforcement, but someone else took control.  They wiretapped phones for 10 months before the compromise was detected; no one ever figured out who did it, but given the sophistication of the attack, it's natural to suspect foreign spy agencies.

For more on the risks of building surveillance into networks, I recommend the following articles:

Risking communications security: Potential hazards of the "Protect America Act"
Internal surveillance, external risks
Tapping, Tapping On My Network Door


Why/when would a CA make a generated public key available to the public at large?

Strictly viewed, it's not correct.  It's not the CA that generates the public and private keys, but the requester.  There's no reason the CA should have access to the private key.  The private key should be kept private (though it's needed to establish every new secure connection, so it must be also on-line).

There's no point in keeping the public key hidden.  By publishing the public keys, the CAs can increase the confidence level in the certificate itself, by giving another path to verify the identity.  The purpose of public key cryptography is that there's no practical way to compute/impersonate the private key with only the public key accessible.

And, despite that, public keys/certificates are not published in all cases - for example, in the case of client certificates, assigned for user email addresses/persons, it might even be dangerous to publish all issued certificates.

On the other hand, publishing server certificates has the advantage that every other entity running servers can verify and confirm that noone else has issued a certificate to someone else for their name - this is actually a subject of a recent initiative called Certificate Transparency.

See - https://www.certificate-transparency.org/known-logs

Update: I agree that the quoted description is quite vague, and somewhat confusing.

Perhaps the poster misunderstood the same way, that the CA publishes any public key that it issues a certificate for.  But it's not what it's about.  What it appears to say, that when the CA initially creates its own certificate, with the public and private keys, it is then sharing that specific initial public key (well, not really, but the whole CA certificate) with the world "at large".  This is the whole the point of a CA certificate - so that everyone finding a certificate issued by this specific CA will be able to verify it with a public key already available, in a way that no third parties can maliciously (at least not easily) interfere with.


From testing, I have demonstrated to clients that yes, both of these are possible. The machines are supposed to have a 1 to 1 relationship with the mouse, but for some types of mouse there aren't a lot of ID codes, so you can get overlap.

The same is true for some wireless keyboards.

Simplest solution: if you are worried at all, use wired devices


Where did common "minimum password length" guidelines originate?

Unix passwords, with the old DES-based crypt() function, were limited to 8 characters (and the high bit of each byte was ignored). Thus, a lower limit of more than 8 characters would simply not have worked.

The driving force for a minimal password size is brute force efficiency: small passwords are unconditionally weak because trying out all combinations of, say, 7 characters, can be done with relatively cheap hardware and not too much time. In particular, in the case of the old DES-based crypt() function, the computational cost of trying one password is low. Therefore, in an "old Unix" context (typical of computer rooms of the 1980s), a minimum size of 8 is the best that can be hoped for, and you really don't want to allow smaller passwords.

I think the "8" comes from that. The rest is a matter of history, sociology, and bananas.


The registrar verifies the identity of the user (in a comment you said that the user is not anonymous towards the registrar). Identification means that each user has some kind of unique identifier. That could be their social security number, their real name + birthday + birthplace or something like that. The registrar uses a cryptographically secure hash function to create a hash from that identifier + a secret pepper only known to the registrar.
The registrar signs the hash with its private key to proof that they generated that hash. Then they give the hash + signature to the user
The user presents hash + signature to the teller. The teller checks that the signature is valid using the registrars public key. Then they use the hash plus another secret pepper only known to the teller as input to create another cryptographically secure hash and then derive the users credentials from that hash.

Retrieving lost credentials

Should the user lose their credentials, they repeat the procedure. Their personal information won't have changed, so the hash by the registrar will be the same as before which means the credentials generated by the teller based on the hash will also be the same.

Possible attack vectors

The largest possible attack vector on this system would be a malicious registrar. When the registrar is evil, they could generate an infinite number of bogus hashes and present them to the teller to generate an infinite number of anonymous identities. Or they could give them the hash of a known identity to obtain the credentials of that user. When the teller knows the registrar, the registrar could still do this by conspiring with another person unknown to the teller and use that person as a proxy. However, you already trust the registrar to identify your users personally, so you must place a very large amount of trust in them anyway.

The abuse potential could be reduced (but not completely removed) by having multiple registrars and require a signature from multiple ones. That way multiple registrars need to conspire to break the system.


How often should I reset my users' session cookies?

Session fixation is an attack where the victim using a vulnerability fixes a session id in the victims browser and then when the user authenticates himself the application does not provide a new session token.  Because of this, the attacker also get authenticated using the victims id.

Session fixation attack won't be possible if the application provides a new session token when logging in and out.  Your current solution is fine and changing session tokens in each request is over-engineering it.  It may also inconvenience the user if they switch networks (such as on a mobile device) if you invalidate it by monitoring the IP.


Can personnel who manage AWS datacenters access my ec2 instances and monitor data in use in my application?

Yes, they can theoretically access or monitor the data.

No, this should not be a concern.  Their incentives (organizationally and individually) to provide a stable, secure service are certainly greater than their incentives to steal your application's data, out of all of the millions of virtual machines and applications that they manage the infrastructure for.

As a developer, there is very little you can do to mitigate this, outside of not hosting with Amazon.  Or any other cloud or managed service provider.  Or collocation facility, for that matter.

Ultimately, any infrastructure that is out of your control is, well, out of your control.  This should not keep you up at night though.  It's like spending your time worrying about being abducted by aliens.  While the risk is theoretically possible, you would get more value for your time by focusing on just about any of the more mundane and realistic risks that your application will actually be in danger of falling prey to, like any of the OWASP Top 10.

Steps you can (and should) take:

So, are there steps that you as an application developer can take to protect your data despite these realities?   Sure, there are several things you can do.

The most basic (and possibly obvious) is don't collect or keep any data you don't absolutely need, and purge the data you do keep as soon as you can.  Less data means less to lose in an attack.

Second, protect the data your application uses.  Start by protecting it in transit.  Use HTTPS/TLS for communications between your application and the users.  This is an effective and inexpensive way to protect it from anyone who has access to the data center network to sniff traffic on the wire.  Protect it at rest as well.  If you have user passwords, protect them with a slow hash algorithm like  bcrypt.  This way, even if the data is accesses, it can't be easily abused.  For other sensitive data you can look at encryption, and major cloud providers these days (Including Amazon AWS and Microsoft Azure) offer cloud-based HSMs for protecting encryption keys.  While still not foolproof, it at least guarantees that someone who gains access to your VMs or disk images won't also capture your encryption keys.

To sum up, there are always steps that you can take that will make your application and data more secure, even when you don't control the infrastructure.  It still boils down to understanding your application and business needs, the realities of how and where it runs, and then threat modeling it correctly for its purpose and environment and mitigating appropriately. From there, following standard secure design, development, and operational practices will help to ensure that your application and data are as safe as they can be.


metasploit: how to use linux/http/webmin_backdoor

TARGETURI is explained in the description for that option; it is the URI path to the application. If you open a web browser to the application and the base of the path is e.g. /webmin, that's what you'd use here. Or, maybe there is no prefix and you can just leave it blank.
The presence of SRVHOST and SRVPORT indicates that the target will need to reach out to a server running on your end as part of the exploit. These just set where that listener will bind, so it can probably be left as default as well. If I remember correctly, Metasploit will use the LHOST value to populate the actual address when the target connects back to this server.


How to fix SSL algorithm for more security

TLS is not broken, only your understanding of TLS ;)

The complete TLS is explained in this answer but to answer you concrete question:

The server does not send the public key simply to the client. The server sends a certificate (chain) to the client.
The client verifies the server certificates with one of the trusted certificates in its store.

So to use a MitM (Man in the Middle)-Attack as you described the attacker has to replace the server certificate (which is also possible but much more difficult).

A certificate is the public key signed by a CA (Certification Authority). So the client can check the servers certificat by verifying the signature on that cerificate.

All certificates have a chain of signed certificates up to a self signed certificate. This self signed certificate is called root certificate and is already included in your browser.

You can create your own CA by issuing a root certificate and use this to sign your own certificates. You then only have to import the created root certificate into the browsers certificate store. This is only feasible for small user bases or for companies with updates to the browsers.


new wildcard certificate if I already own another certificate for a subdomain

There is no reason you can not use both certificates.

However take note that a wildcard certificate is only valid for a single leaf (so something.example.com and not invalid.something.example.com)

the 2 certificates are completely independent of each other.
It is even possible (although that would break CA guidelines) to issue multiple certificates for the same FQDN.


At risk of sounding very pessimistic, a website using HTTPS actually says almost nothing about how secure a website is, unfortunately. All it tells you is that they use an accepted mechanism to secure the communication link between you and them.

Unfortunately:

the encryption used on this link could be insecure
you may be connecting to a malicious man-in-the-middle, and if you don't know how certificates work you may not spot this
the website itself may have many insecurities
the server the website is hosted on may be vulnerable
etc.

The only real benefit is that if HTTPS is used correctly, your communication is encrypted, which does provide an increased level of security for the end user than a site which doesn't.

correct in this scenario means:

you trust that the certificate presented to your browser is the one for the website your are trying to get to (your mileage may vary)
the version of SSL on the server is up to date and is only using strong algorithms (have a look here)

But as I said before, this can tell you nothing about the security of the server itself.


AWS RDS MySQL database publically avalible

Database protocols are not designed to support hostile public exposure. Even source IP protections may be insufficient, due to IP spoofing, lack of transit encryption and other issues.

Perhaps reconsider the architecture by either using a read replica in the second region and sending customers who need to do writes to the EC2s in the master region, or just by shutting down the other region EC2 instance.

The other-region deployment of EC2 may not help for performance, because transactions still have to travel to the master region. And it may not help for availability, because if the master region is lost then presumably the lone EC2 instance won't be able to do very much.


The methodology you are looking at is not designed for penetration testing.

From the same url at that website:

The aim of system test is to test all of the following areas.

Scheduling software
Day-to-day operational procedures
Backup recovery strategy
Management and scheduling tools
Overnight processing
Query performance

...and..

There are a number of aspects that need to be tested. These aspects are listed below.

Security - A separate security document is required for security testing. This document contains a list of disallowed operations and devising tests for each.

That said when performing penetration testing against a Data Warehouse the areas that are usually unique fall into the use of non-standard databases and nonstandard protocols. These are frequently, but not always, NoSQL databases like Hadoop, Apache Spark, Cassandra, MongoDB, Green Plum many of these have their own unique vulnerabilities or use very unique protocols or messaging systems which have to be tested separately. Likewise some of these like Hadoop tend to extend database administration rights to the attached systems due to the way some of the protocols work (deployments may vary). Testing and securing these systems is a huge issue beyond the scope this type of answer but hopefully this helps you with your testing process.

As a side note: Penetration testing AWS services, especially the server-less components like Lambda can be very unique so you'll have to do all that work as well. Again this is beyond the scope of your question but I thought I'd mention it as it's directly relevant to the details in the question you asked.


Is it safe to provide my details via an iframe, if the page in the iframe is secured with SSL?

It's a bad design and the entire page should use HTTPS, as this trains users to the unsafe practice of trusting and submitting private information over HTTP.  It would be trivial for a man-in-the-middle attacker to alter the outer HTTP page to not use the correct HTTPS iframe, but instead an attacker controlled iframe (possibly HTTPS to an attacker controlled domain).

Thus you need to check the source code of the iframe every time you submit private data (as there are no guarantees that the first time you inspected it was fine, but the next time it was altered by an HTTP tamperer).

Furthermore, as the page is loaded over HTTP, a MITM attacker could insert and run whatever javascript they want on the outer page (and hide these modifications in some obfuscated script that's loaded externally).  They could leave the original iframe with the right https URL if you clicked view-source of the HTML page, but in javascript they could hide or replace that iframe with malicious DOM elements that look identical (but leak your details to the attacker).  This is less of a problem with an interactive DOM inspector in modern developer tools (which shows the DOM as it currently exists, so you should be able to inspect the iframe), but again this requires a lot of verification work for every user who wants to safely submit data.


Why should password authentication require sending the password?

The reason for passwords sent either in plain text or hashed are mainly historical. In the old days when we used dumb terminal over serial lines (70's to 80's), only plain text solutions were possible. Well One Time Password like S/Key also existed but you needed the hardcopy list with you...

Then came the era of PC, Windows and Lan Manager. Microsoft fellows knew that ethernet networks were too easy to spy, so they decided to only exchange challenges. The counterpart was that is was necessary to store the password in an invertible form on the server.

The usage of crypto became more popular with SSL, and many protocols were adapted to use encrypted channels (HTTP -> HTTPS for example). And admins re-discovered the benefits of only storing hashes on their servers: if the password database is compromised, you have plenty of time to change the passwords.

That's the reason why best practices are nowadays to exchange password over encrypted channels and store salted hashes on servers, and why other practices have existed...


You are assuming that once you are authenticated to the Access Point that you can automatically see all WiFi traffic from all nodes in the clear.

In WPA, each node is given their unique key with which to communicate with the Access Point.


Any tools like PuTTY for manually stepping through network communications?

The problem with what your asking for is that there isn't a 1 to 1 mapping of the OSI layer to actual implementations. The OSI layers are really conceptual more than physical. In reality, the demarcation between the various layers is very blurred, which makes it near impossible to implement a tool which can break things up and break them into specifric layer operations. I have seen some simulators used for teaching purposes, but don't know of any which are free or open source. Being simulators, there is only a limited amount of value in them anyway.

My recommendation would be to use wireshark to monitor traffic and then perform some standard activities, such as an http and https session, a telnet/ftp session, sending a email message, ping, traceroute etc. You can capture the traffic and then use wireshark to inspect what is going on. As a tool, it is very powerful, but like most powerful tools, it can take a while to learn. However, the interface and filtering options are pretty good and it provides a good way to 'zero in' on various levels of the network traffic.


openssl ECDHE-RSA... cipher suite selected while using RSA server cert and ECDSA client cert

"ECDHE" means that the key exchange will use the Diffie-Hellman algorithm (over elliptic curves) with freshly generated DH elements; the last "E" stands for ephemeral. So while DH produces a shared key, it will work with randomly produced values, and nothing in DH will ensure authentication: the client has no way to know whether the DH public key it sees really belongs to the intended server.

To bring back server authentication, something else is needed. It is a signature: the server digitally signs its half of the DH key exchange. That signature uses the key which is in the server's certificate, and thus the signature algorithm depends on the type of that key. In "ECDHE-RSA", the "RSA" part relates to that signature: it says that it will be of type RSA (and implies, of course, that the server's certificate contains the corresponding RSA public key).

There is no such mechanism for client authentication. When the server requests a client certificate, the client will have to compute a signature and send its public key (as part of its certificate), but there is no relation between that client certificate type and the cipher suite. The reasons for that are:

Client certificates appear later in the handshake, after the cipher suite selection. When the cipher suite is chosen, the client does not yet know whether a client certificate will be requested at all.
A SSL server, in general, must be able to answer to the whole World, but when the client connects, it knows what server it is talking to, and can select an appropriate certificate in consequence (the server also sends a list of CA names to narrow down the client choices). Client certificates are a rarity in a Web context; in all generality, SSL servers ask for client certificates when they know that the clients already have certificates of an appropriate type (e.g. a bank server will ask a customer's certificate only if the customer is part of a program in which the bank ensured distribution of the said certificates). Therefore, there is no need for a dynamic negotiation of the client certificate type.

The cipher suite selection is all about choosing algorithms which are supported at both ends. If the server must sign, and the client verify, then the client must be able to understand the signature algorithm and thus its key type.

In practice, the client sends a list of supported cipher suites, and the server selects one of them -- a cipher suite that, of course, corresponds to the algorithms and key types that the server is going to use. Theoretically, the list sent by the client is ordered by "preference" and the server is supposed to honour that order, i.e. choose the first cipher suite in the client list that also fits the server's abilities. Not all servers are that courteous.

See this answer for an introduction to SSL/TLS.


The law is about what you are allowed to store and targets your infrastructure. And the law is intended to give the user control over his data.

The client cache belongs to the client's infrastructure in any reasonable definition and already is under control of the user.

This may be interpreted differently when you try things like supercookies which stay even when history is deleted or other sneaky tricks, but as long as you're just speaking about the usual client cache this is nothing you're actively storing and nothing you have direct access to.

But be aware of other caches. Maybe your load balancer caches responses with a cache header which allows caching. Then people can argument that you still have data about them stored. It may not be too easy to access, but it is there, could be accessed or may leak when you're hacked.

Disclaimer: I am not a lawyer and you might want to find one. Currently nobody knows for sure what will actually get you sued and what not.


Compromised Wordpress Admin account risk

The short answer is that such a compromise would give an attacker the capability to do anything that an admin could do. That would likely include:

Altering theme files
Installing plugins
Accessing the (Wordpress) database

Etc.

Of course, the admin would have the ability to install malicious plugins/files (like a webshell) as well.

  But any other risk beyond the wordpress site itself?

It's safe to assume "yes" - that there would be additional risk.

Without going into a huge amount of detail, the damage that could be done would be a product of:

Your webserver configuration (did you chroot your web files)?
The permissions with which the php executable runs
How prudent you've been setting file permissions throughout your server. Have you made any important files world-writeable?

Regarding that last point: of course, even if your "important" files aren't world writable, they may very well be world readable.

I'm not trying to self-promote here, but you might want to take a look at this webshell platform I made:

https://github.com/chrisallenlane/wash

I demo compromising a Wordpress application on YouTube. This gives you a pretty reasonable overview of the kind of trouble an attacker could cause:

https://www.youtube.com/watch?v=UPaUync0TVA

Please forgive the low-quality, monotonous video :)

TL;DR: if I had an admin account compromised, I personally would consider the entire system compromised and rebuild it from scratch, were that an option.


Security Configuration Audit - CIS benchmarks

Aside from CIS Benchmarks, I suggest what the U.S. government uses for FedRAMP clouds which are the USGCB checklists and the DISA STIGS.


Why is PHPs $_REQUEST considered to be evil?

This is because it widens the scope of reflective XSS to POST requests, as most scripts don't check the HTTP verb explicitly.

Imagine you've got the following code in a script that usually expects a POST request:

<?php
if (($order = $orders->fetch($_REQUEST['id'])) === FALSE)
{
    die('Could not find order number ' . $_REQUEST['id']);
}
...

If $_POST were used, the XSS vulnerability would still exist, but it could only be triggered by a user going to an attacker-controlled page first so that a form could send the exploit via POST. Instead, the attacker only needs to get the victim to click a link such as:

http://example.com/vulnerable.php?id=<script>alert(document.cookie);</script>

It's also a concern for other verb-confusion attacks, where two parts of the script make separate judgements on the verb being used (e.g. one assumes it's a GET, the other a POST) resulting in unexpected behaviour.


Depends on your hardware. But most actual routers allow the use of virtual networks (vlan). That should be sufficient for a home network.