Relationship between http time response and geo-location

On a reliable way, there isn't. The reasons:

There are many other circumstances which can increase the response time. For example, if there is a virtualized system or it is overloaded. Or its network is overloaded.
The TCP protocol uses a windowing scheme, which results you won't get not the ACKs to the actually received packets, but usually for 8 packets earlier, and it depends on the speed of the remote system to process these packets.
The topology of the networks is graph-like on the highest level (around from the country-level routing), while it is tree-like below that. The delay times are maybe reliable on the first, but start to be unreliable below that.
Even if it would work, you can get only a "distance" information which is very far from the localization.

But:

On sending the first TCP packet, the TCP window is nearly empty yet, so the delay of the first ACK packet is practically reliable delay information. It can be used essentially as a tcp-based ping.
If you have access to large server logs, you can construct a database from the typical delay time from every registered IP network on the net. It would be useful if you would store not only the mean value of the packet delay, but also their standard deviation.
If you have access to multiple servers, on widely remote places and network on the world (for example, one in middle Europe, other in New Zeeland), you can build a such timing database for all of them.
These databases should depend not only on the remote IP networks, but also on the time of the day, and of the day of the week (these network load depends mainly on these).

After that, based on a floating-point extension of the Bayes theorem (maybe extended with a little bit of fuzzy logic) you will be able to get a "beliavibility factor" of the IP delays. But it will result in most cases misleading results, because the cause of the unrealistic delays is in most cases on the last mile, and only in a relatively small part of obvious forgery.

But, if you connect this "suspectively behaving" IPs to other security logs, it can maybe serve as an useful source of "soft data". For example, it could be usable to heighten the sensitivity of spam filters or alarming firewalls.

It requires math on around the third-fourth semester of most universities, and at least one professional & senior programmer.

The things to be developed:

Building a such database and its hw/sw integration
Building the network monitoring scripts
And building the IP localizing script based on the network delay stats of an individual IP.

I would say it would be between a week and a half year of development, based on the details.

If you have enough machines, you can build a delay database even between nearly all networks on the Earth, which could be even used maybe for the localization of their real location. But it would be much harder.


How can someone determine where a wireless router/SSID originated?

If you have an Android smartphone or tablet, you can use the WiFi Analyzer app. It has a screen dedicated to detecting the proximity of access points.

Walk around and see where the signal is the strongest.


System Encryption With Veracrypt/Truecrypt- What is the difference between Wipe Mode "None" and 3 pass, 1 pass etc?

To answer the specific points you brought up let me take them one at a time, and note that this answer is specifically for NON SSD drives.

As long as nobody ever gets your password then there's no point to wiping the freespace.  The benefit to wiping the freespace is that in a normal systme when files are deleted, the are they are stored at is simply marked as 'available', so the file contents are still on the disk.  When you encrypt your whole drive you're also encrypting those remnants of previously deleted files.  This means if your password is ever compromised and decrypted, those files you 'deleted' prior to encryption may be recoverable.
If you want to learn more about the differences between a single pass wipe and a multiple pass check out the answer to this question.
In this case there really is no discernible difference between a single pass and a 3 pass wipe.  Some people just like doing a 3 pass because that's what they're used to doing in the past.
All your data after encrypting with a strong password is safe as long as you also don't write your password down, or re-use that password, etc. (apply all standard good password practices). The one possible exception would be bad sectors where the drive has failed, and can't normally retrieve data from that location, but a forensic lab could recover data from those damaged sectors.  The only way to prevent that is to encrypt the drive when it's brand new.


Can XOR be used in a Merkle Tree instead of concatenation?

No, you cannot use XOR as you would not be able to distinguish the order of the values underlying the hash tree: H(H(x) ⊕ H(y)) ≡ H(H(y) ⊕ H(x)).

Furthermore you can create hashes over all zeros by inputting identical values: H(H(x) ⊕ H(x)) ≡ H(H(y) ⊕ H(y)).

So you cannot use this for a generic Merkle tree.


Cookie Operations using Modsecurity Rules

This is a lua script, why are you doing first a secrule then chain, you better call the script and get the var REQUEST_FILENAME and check it matches your pattern or add a Location/LocationMatch for the path and add the SecRuleScript inside.

The first rule is incomplete as it is a chain start that has no end as the next one is not a rule is a script call.


Preventing CSRF/XSS on mobile/web shared API

I think your best solution would be to move the access token from a cookie to local storage. It's simple and efficient.

So what about the concerns you raise? You are right that this exposes the token to XSS. But if you do have XSS vulnerabilities, it's effectively game over anyway. The HttpOnly flag is an annoyance to an attacker, it's not a solid defence. I would not pick a more complicated design just to be able to keep the token away from JS. Instead, spend the time you save on hunting down actual XSS vulnerabilities!

As for malicious browser plugins, there is no way you can defend against them no matter where you store your tokens. If the client is infected with malware, you have already lost. So from the perspective of an API developer, there is no point in even trying to defend against this scenario. Your users need to keep their machines clean; if they fail at that there is nothing you can do for them.

Splitting the API gives your more maintainance work in the future, and sort of negates the whole benefit with having an API. To me, it smells like an ugly emergency solution that I would stay away from.

Finally, a strict CSP is always a good idea. It's not a silver bullet, but it sure helps a lot.


Are there any tools that focus on shellcode analysis?

Since shellcode is just a raw block of instructions, these tools aren't really suited.

Wat? Executables are just raw blocks of instructions too! No really. Ok, maybe there's bits of data in there for PE/ELF headers or the like, or just plain program data, but the data is the same binary as instructions. To the point sections of executables are labelled (text, data) so the OS knows what to treat as what.

For a demo, take any set of assembler and type:

nasm -f bin <asmfile.asm>

That'll do absolutely no additional work bar translating the assembler instructions to opcodes and writing it down in a binary file. This is how you'd go about writing a bootloader or the like.

Now, if you wanted to analyse some shellcode, there's a multitude of ways you could do it. For starters, you could just use a harness:

#include <stdio.h>

char shellcode[] = { ... };

int main()
{
    int (*function)() = shellcode;
    function();
}

and voila you're off - simply get gdb or the like to single step through it. Of course, if you wanted to analyse that particularl piece of shell code statically, well, there's a way for that too:

#include <stdio.h>

char shellcode[] = { ... };

int main()
{
    FILE* f = fopen('test.bin', 'wb');
    fwrite(shellcode, sizeof(shellcode), f);
    fclose(f);
}

and now you have a binary blob to work with. Actually, chances are you had to do the inverse of this to load the code into the test harness (i.e. escape it) anyway.

If you're looking for tools, I suggest the x86 wikibook. Basically, it comes down to picking one or more you can afford and having a play.

Unless the shellcode contains anti-debugging measures (remember, it's space-constrained) chances are a runtime debugger with the test harness will work just fine.


Is there a GNU/Linux or BSD distribution dedicated to air-gapped computer?

As far as I am aware there are none, it's quite a specific niche. Nevertheless it should be easy to configure any of the BSDs/Linux Distro's to serve your needs.

I speak mostly from FreeBSD experience but it should be pretty similar for other BSDs and Linux. It's easy to compile a kernel and just deselect all networking stuff. On an average cpu this takes 3-5 minutes for Freebsd. Probably even faster if you exclude a lot of things. In addition to this you could disable the network ports in the bios.

But you should be asking yourself what your threat model is and whether you want 'online' or 'offline' signing/key generation. If your threat model includes local attackers, do you even want a system that is running continuously? Vulnerable to cold boot attacks, badusb attacks and bios exploits?

If I were to setup a separate air gapped system, I would simply use a tails or freebsd live cd. Use a write once cd-r/dvd-r. After you've written it you can confirm on multiple independent machines via checksums that you have a live cd that has not been tampered with. Now use this live cd to boot on your 'air gapped' hardware and once booted you decrypt an hard drive with your secret keys and you can do your operations.

Advantage of using a live cd is that you can keep it updated by simply creating a new one that has patches included. If you were to setup a separate system without networking it would be tricky to keep updated/secure. By only booting the live cd when necessary and thus leaving the hard drive offline and encrypted you also avoid being vulnerable to cold boot attacks or other local host attacks against a running system.

So some food for thought, first properly define what your threat model is; who or what are you looking to defend against? And then address that.

Another solution could be something like a usbarmory, it's a fully functional computer with no input devices other than usb. Very tamper proof and small enough that you're able to keep the device with you at all times.

Now let's talk about entropy. There is a variety of things you could do here, obviously the more entropy the better. I think the random number generator of neither Freebsd, OpenBSD or Linux can be considered vastly superior to the others. They're all quite solid.

Some extra reading material: RNG of Linux, RNG of OpenBSD and RNG of FreeBSD

All of them do a good job of mixing different sources of randomness. If you want extra randomness because there aren't a lot of entropy sources you could consider getting an extra separate hardware RNG, for example OneRNG.

All distros/bsds will come with OpenSSL preinstalled, OpenBSD will come with LibreSSL. LibreSSL can also easily be installed on Freebsd. So all common cryptographic operations should be doable out of the box.


Yes, a PFX file (which follows the PKCS#12 cryptography storage format) such as the one you have does contain a key so it would be a keystore.

You can use PKCS#12 files natively as a keystore for most crypto implementations - for instance for its usage as a keystore in Java see the accepted answer for "Keystore type: which one to use?" for a very illustrative description on the various types of keystores.


Why even store it in a MySQL database when you can be using Authorize.Net's Customer Information Manager API and taking PCI compliance and security issues right out of your hands completely and letting them do all of the heaving lifting for you? CIM let's you create customer payment profiles by storing the customer's credit card information on their end and then charging against that profile at a future date whenever you need to simply by referring to the payment profile ID at the time of the transaction.


Flash and Software based vulnerabilities

It is (in my opinion) possible to spread Flash Mal easily through every possible source:

Obscure Social Media/Sharing Sites
Email Scams
Advertising Networks
Hacked websites riddled with hidden flash content

For example 18 Hours Ago (from this post) Adobe fixed a vulnerability (CVE-2015-7645)

There was a reason Steve Jobs never wanted Flash on iOS


What does colluded truncation attack mean?

Have a read of this paper from the University of Missouri-Kansas City for a bit of info on this - it doesn't go into depth on the problem of colluded truncation attacks, but has some mitigation theory.

The idea is that where mobile agents are collecting data, an attacker may try to truncate data in order to alter results, hide information etc. This is usually protected against by having data signed at each server, on receipt and sending.

A collusion between 2 or more hosts may be able to still alter the data in a way beneficial to them without it being discovered. This is a colluded truncation attack.


How to confirm the last entry of a linked hash list

You need to save a MAC (also named "tag" sometimes) of the last entry at a safe place. What safe means here depends on your threat model, but it should at least resit to the following attack:
Be warned that if the attacker can read this MAC at any point in time and has write access to it, it can restore the chain to a previous version by overwriting the MAC. For this the attacker does not need to know the secret authentication key used to compute the MAC.
To prevent a rollback of your chain, you must ensure that the MAC cannot be rolled back without noticing. This might be done for example by using a web service to store it and keep its history.
It was suggested to you to insert this MAC in the first node of the chain. If this MAC were part of the hashed data of the first node, this would introduce an unsolvable cycle of hashes. Thus, the MAC of the last node must be saved outside the structure of the hashed chain.
As a side note, this MAC can be based on a hash function like HMAC-SHA256, or it can be a fast (and still secure) MAC like SipHash. Other secure algorithms exist, but just ensure that the produced tag is at least 128 bits long and that the secret key is generated by a CSPRNG and of at least 128 bits.


Suspicious site activity on www.computerworld.com

If you closed the tab and all the popups, or better the whole browser. And "popups" kept opening. You're likely infected with malware (or visiting multiple suspicious sites at the same time).

Run some antivirus and anti malware scans,
Make sure everything is up-to-date,
Install an ad blocker or (stricter) popup blocker.


Securing Public Web Services - What is the best practice?

Asking for the best practice to secure some public service, without any other detail, is like asking what is the best car. The only answer can be: it depends. Do you need the car to transport heavy equipment ? To reliably go to work even in a snow storm ? To roam the streets for hours as part of a vigilante group ? To woo prospective mates ?

Since we are talking generalities, then the first thing to do is to write down the security model:

What assets are you trying to protect ?
What is the assumed extent of the power, motivation and patience of the attackers ?
What is the value of that which you protect ?

In particular, for a public network-based service, you may or may not fear the following cases (non-exhaustive list):

An attacker sends a request to your service without being authorized to do so.
An attacker spies on the data exchanged between your service and an authorized user.
An attacker modifies a request from an authorized user to your service, and/or modifies the response.
An attacker poses as a fake clone of your service, and talks to your users without your service being ever made aware of it.
An attacker disrupts your service by overloading it.
An authorized user spies upon other authorized users accessing the service at the same time.
Legal authorities ask you to provide the identity of the user who issued a specific request to your service, and you are legally obliged to keep such logs.
Some local event (flood, fire,...) takes your service down and you need to activate a secondary site to maintain availability.
Users sue you for some alleged framing and you must have a proof, convincing for judge, that the user really sent you a specific request that you could not have fabricated (a typical banking context).
An attacker succeeded in stealing a part of your server's database, and uses it to impersonate users.

A variety of tools will be relevant, depending on the situation. In most cases, using SSL for your service will be a good idea (or, rather, not using SSL would be a spectacularly bad idea). In many cases, you will need some form of user authentication.


You want to run a port scanner. The king of port scanners is nmap.

You can configure it to scan a range of IPs on a selection of ports. Test it on your machine first, from another machine, to see how the results behave. If you get useful results, then scan the IPs you want to inspect.

There are lots of considerations, though. Like firewalls, routing, subnets, etc. But those are networking concerns.


Does content-type header having a blank value in the response body, cause any security problem?

A Content-Type header is applicable to a response with a body per RFC 2616:

When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding.

By extension, it's not necessary if there is no response body, as you're describing.
It is a SHOULD and not a MUST, so it is RFC-compliant to not include that header even if there is a response body:

Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body.

As @Elhitch says, when the client has to guess what the Content-Type is, it's possible it will guess wrong with negative implications.  But that doesn't apply to your use case of 'No content value (No response body)'.


Lots of SSH tries on my log. Is it normal?

There are already numerous questions about this, here, on Serverfault and Unix&Linux. I'm on mobile so I unfortunately can't link them, but if you search for "SSH bruteforce" you'll find a highly upvoted question on each of these sites.

Basically, you should stop thinking your "Raspberry Pi" (gosh I'm starting to hate this name) is something special. It's not, it's just a standard Linux machine and all questions and security procedures that apply to Linux machines also apply to it.

Once you start thinking right you can browse the many questions the SE network has about securing servers.

For your particular case, a quick solution would be to switch to keys and disable password authentication entirely (that takes care of the security issue, so attackers can't do any mischief), and change the SSH port to something non-standard such as 2222 so that you get less noise in your logs (despite switching to keys, these automated break in attempts will continue, and while they can no longer break in they'll still flood your logs).


Can you just replace the TLS cert in a pinned application?

Is it really that simple?

Generally, yes.

  It would be extremely trivial to write an automated tool that decompiles the app, searches contents for cert file extensions and/or greps for -----BEGIN PUBLIC KEY/CERTIFICATE----- and use openssl to generate a new cert and replace it which can then be used to sniff the ssl pinned traffic.

So?

SSL, with or without certificate pinning, is not designed to defend against a local on-client attack. It is designed to defend against data interception by arbitrary middlemen (e.g., ISPs, the coffee shop WiFi router) from arbitrary clients.


The remediation level is a property of the vulnerability: is it fixed or not?

Let's translate each level to CVE-2016-3714 to see a concrete example:

Unavailable: there's no fix or mitigation available. Most bugs start in this level
Workaround: the developers have yet to pitch in, but you can mitigate the risk by checking the magic number of uploaded images and only allowing whitelisted formats
Temporary fix: the developers are working on a patch, meanwhile they recommend to add this policy to your policy.xml file.
Official fix: an official patch has been released, you should upgrade your install.

The question thus becomes "At what point is a patch considered released?"

This will vary for each project: for some it's when the fix hits their "trunk" branch, for others it's when the update hits the auto-updater, for a distro it's when it hits the official repositories.

It's something that has to be defined by the project and is beyond CVSS' scope.

If you don't know how you should define it, think how your users got hold of your software in the first place and consider anything released through that same channel as released.


Bypassing HTTP to HTTPS cached 301 redirect to use SSLstrip

If you can make the browser make a request to http://targetaddress.com/whatever . The browser will default make a plain HTTP request, not an HTTPS one as there is no cached response for /whatever, only for /.

This can be achieved in several ways. One way is to MITM between the browser and any website accessible through plain HTTP and insert an <img> tag. Another way is to trick the user to enter targetaddress.com/whatever in the address bar through social engineering.

As soon as the browser makes a clear-text request to the target domain, the MITM has won the game.

HTTP enables a client to perform actions on entities. Which action is performed depends on the HTTP method specified in the request. Which entity the action is performed on depends on the URL specified in the request.

Different URLs can reference the same entity, but the browser does not know this. When a browser caches an HTTP response, it does so for a given URL.

http://www.target.com/ is an URL. http://target.com/ is another one. http://www.target.com/whatever is yet another one. So is http://www.target.com/?.

Now, suppose there is a cached entry for http://www.target.com/ in a browser. Does it implies there is one for any of the other URLs listed above? No, it does not.

Thus, getting back to the question, making the browser send a plain text request in the case where a permanent redirect is returned by a Web application on the HTTP port is a matter of crafting an URL which does not match a cache entry and tricking the user to visit this URL.

Proof this works:

127.0.0.1 - - [13/Apr/2016:10:01:17 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:01:35 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:10 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:36 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:16 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:25 +0200] "GET /? HTTP/1.1" 301 227 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

I have been able to make six (arbitrary number) clear text HTTP requests to the same Web site with the same browser even though a permanent redirect is configured for everything. (And no, I did not clear the browser's cache!)

Other obvious ways to work around a permanent redirect include tricking the user into switching to anonymous browser mode (no cache) or switching to another browser ("I have issues when accessing the app with IE. Can you have a look?").


Is there a way to post directly to the server without going client side?

I was pentesting a web app and while doing a password reset, they
  check for the old password only in the client side but not in the
  server side.

They could be taking your current password at the client side and encrypting it or creating a random token from that password and other info and then sending it to the sever along with the new password for processing or Simply checking for the password at client side and then send some random number if the condition were true or false.Why?No reason but they could.

  So would it be possible to post directly to the server and changing
  the password without going client side?

Yes,if and only if there is no current password or CSRF token in the request or a encrypted token that cannot be figured out by attacker then yes the web app in question is wide open to password change CSRF attack.You could easily make a POST/GET request and then lure the victim to an attacker site and change his password.

NOTE:-You might be missing a couple of check's.Keep poking.

  What to do next?

Try and make the request for password change using burp repeater and take away all the cookies one by one and look at the bare minimum needed to make the request and you will know the answer


Video site requests Adblocker to be shut off, next day I have 3 "weird" bookmarks

What you describe is a wrong, spam practice but it does not cause other inconvenience over the spam aspect.

Browsers allow JavaScript code initiated by a user click to add bookmarks in order to allow websites to propose friendly "Bookmark this site" buttons. However such functionality can be exploited in order to store unwanted bookmarks in visitors browser linking to remunerated links (pay per click abuse).


Can a tor exit node know the ip of .onion sites?

No, a Tor exit node does not know the IP of a .onion site. The only node that knows the real IP of a .onion site is a special node called guard node. It's the first node the hidden service connects to, so it knows the real IP.


Online votes where two-part codes are sent together

I've received similar two-code mailings for various elections as well.  The same concern hit me, so I looked at them more closely.

One thing that struck me is that the same companies host many thousands of elections.  So there's more going on here than a simple election.

For consistency and branding, the voting sites are customized to the organization, so every year for my Coop, I log in to the same URL, something like https://my.coop.election.example.com/ and cast my ballot.  As far as I can tell, the URL simply determines the CSS displayed so the right logos and colors show up; but underneath the exact same web site serves all their customers and elections.

From this it made sense that the first code identified the specific election ("2018 My Coop Board of Trustees", "2017 My Coop Board of Trustees", etc.), and the other identified me as the voter.  If true, this isn't two-factor authentication, it's simply a pair of identifiers.

As I recall they were named something generic, like "Code 1" and "Code 2" instead of "Election Number" and "Voter ID".  This may be intended to keep things obscure; to keep people from trying to vote in other elections or trying to guess someone else's Voter ID.

Could they do this differently, like combining the two and issuing a giant SHA-1 hashed number for me to enter?  Yes, but the usability of typing in a very long number is difficult, and they are trying to keep both usability and integrity high -- two shorter numbers are easier to type, and probably solves their problems for them.


DDoS: A protocol where the victim says "Don't send me traffic for N ms"?

Although this sounds like a nice idea in theory, I think there are a few reasons why this hasn't been implemented yet and won't be implemented. They mostly have to do with complexity and scalability:

If every router on the internet needs to keep track of requests from every host to throttle traffic, this would result into a very large database every router needs to update and check for every packet being routed. This has a huge impact on the router's performance.

A second thing to consider is that things like this only work if it's widely supported. Solutions like you proposed are complex, and before consensus can be found in the IETF to define standards on how to implement this (if it is found at all) a lot of time will have passed. After that, even more time passes before a large amount of routers on the internet have upgraded to software which has implemented such a feature. All in all, it can easily take a number of years before such an idea is converted into an implemented standard.

Another problem is trust. You'll need to provide some mechanism to make sure that the host or router claiming to request throttling is actually responsible for hosting that IP. Without this, the mechanism could actually be used as a tool for doing a DDoS attack, by spoofing requests for throttling for the target, thus stopping all traffic towards the host. Routing and trust is still a very complex combination. BGP, the dynamic routing protocol on which the internet is built, is still mostly based on trust, and more and more it's clear that there are a lot of people operating networks on the internet you simply cannot trust. Solutions like RPKI and BGPsec are still not widely deployed. Adding yet trust based another mechanism will make things only more complicated.

And last but not least: not everyone benefits from not sending packets. If packets are queued, this may be a burden on networks along the path. But even if that's not the case: many networks make money by transporting packets, and transporting less packets means earning less money. If a network has a direct relationship with the network under attack the may consider it a (possibly paid) service, if not, they might be reducing their income by throttling. Of course, plenty of networks also focus the good of the internet, but may won't, and that would mean that the idea won't work that well.


How to ensure the traffic between vm and host doesn't mix in Windows?

If you use a bridged configuration then NAT will not occur. The guest system will request and configure its own IP address from the adjacent segment. If you have the guest configured in a shared configuration then an IP addressed will be assigned by your virtualization software and NAT will be used to communicate with the adjacent network segment.


Can you Encrypt your HOST Machine, while Inside an emulated Virtual Machine?

If I understand your question correctly, what you are after is not possible. The reason for this is that encryption can protect data while it is transit or at rest, but not while it is being processed. As the comments stated the host OS must be running in order to run the guest, so you cannot encrypt the Ubuntu partition that is also running your VMs.
A solution is to either make a dedicated machine as a hypervisor (which if you run without a GUI will consume less resources and need less patching) or to encrypt any sensitive files on your host using file encryption. An example of a program that can encrypt individual folders or the entire drive (which will not work for this use case) is Veracrypt. After creating the secured folder/container with Veracrypt, you could decrypt it only when you need access to the contents and running your VM, leaving it encrypted whenever you use the VM so that if a VM escape exploit does occur the attacker can still not read your data.
EDIT: Just making it clear that this answer is based on the below quote from the question;

say for example: UBUNTU(host machine):->run VM(Arch) and have Ubuntu be completely Encrypted whilst in the Arch VM?

You can encrypt your host/hypervisor with disk encryption to protect data during transport or rest, but you cannot have the host/hypervisor encrypted while it is actually running VMs.


Is a plain password in the URL a potential security threat?

This is a serious security problem. URLs should never contain sensitive information.

URLs show up in your browsing history. So even after logging out it will be trivial to access your account for anyone using the same computer.
Commonly, web servers are logging incoming requests. Also, firewalls or proxies involved in processing your requests might maintain their own log files. In that case your credentials will show up all over these logs, increasing the risk of a leak.
If they show you your password in plain text that probably means they are also storing it unhashed. That means, if there ever happens to be a breach of their database, your password will be disclosed.
Many browser plugins send visited URLs to their servers, e.g. to check them against a list malware sites or just to spy on you. It's bad enough that they are able to track people's browsing behavior. With credentials in the URL it's even worse.
Referer leaks. If they include analytics (I'm sure they do) or embed advertisement, or whenever you click on an external link, your browser typically sends a Referer header which contains the previous URL, thus disclosing your credentials to all these parties.

  should I be concerned and thus change all of my passwords and pattern?

Yes, it's such a blatant flaw that you shouldn't put any trust in their systems. Sticking to your password is not worth taking the risk.
It's their own responsibility to fix the application and as a user there is not much you can do about it. Kindly inform them about the problem and refrain from using their services.


Windows documentation includes a section regarding Security Considerations: International Features that may be worth a read, specifically involving Unicode normalization.

To answer your question: in a vacuum, assuming the user has no access to the system other than through your program, your code is fine.
That said, if an attacker has access to certain features, such as creating symbolic links/directory junctions, then it could be possible to bypass your security check.  They would simply need to create a directory junction inside the \Data directory that points elsewhere, then access files through the junction  instead.

Additionally, keep in mind that the attacker may have control over the variable you have labeled as CurrentPath.  In Windows, you can run a program with a specified working directory even if that directory isn't the one the executable resides in.  Combined with directory junctions, if there exists any location that the attacker can create a directory junction, they can potentially exploit your program.

Lastly, it may be worth noting that NTFS has some pretty niche features.  On top of that, Windows supports multiple file and directory naming schemes.  I'm not certain if any of these are directly exploitable in this situation, but they're worth keeping in mind.


How can I sandbox a Wine application on Linux?

You can run wine inside of docker containers to isolate it from your host system.
docker does not support GUI applications on its own, but it is possible.

Have a look at x11docker to run GUI applications in docker. There is also a description of short setups without x11docker.

There is also a ready-to-use wine image at docker hub: x11docker/lxde-wine

Example: wine on dockered LXDE desktop (needs a nested X server like e.g. Xephyr):

x11docker --desktop --home x11docker/lxde-wine

The image contains PlayOnLinux, too. Run Playonlinux with:

x11docker --home x11docker/lxde-wine playonlinux

(Option --home creates a persistant home folder for wine container to preserve installed wine installations.)

Disclaimer: I am the author of x11docker, sorry for advertising

Setup without x11docker to provide an independent answer. It lacks some x11docker security features, but basically it works and is much better than installing wine on host:

Dockerfile to build a wine+PlayOnLinux image:

FROM debian:stretch
ENV DEBIAN_FRONTEND noninteractive

# contrib for winetricks, stretch-backports for latest wine
RUN echo "deb http://deb.debian.org/debian stretch contrib" >> /etc/apt/sources.list && \
    echo "deb http://deb.debian.org/debian stretch-backports main" >> /etc/apt/sources.list

# Multiarch for wine32, wine, some often needed dependencies:
RUN dpkg --add-architecture i386 && apt-get update && \
    apt-get -t stretch-backports install -y wine

# helpful additions
RUN apt-get install -y fonts-wine winetricks ttf-mscorefonts-installer winbind

# wine gecko and mono
RUN mkdir -p /usr/share/wine/gecko && \
    cd /usr/share/wine/gecko && wget https://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86.msi && \
    wget https://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86_64.msi && \
    mkdir -p /usr/share/wine/mono && \
    cd /usr/share/wine/mono  && wget https://dl.winehq.org/wine/wine-mono/4.7.1/wine-mono-4.7.1.msi

# PlayOnLinux
RUN apt-get install -y playonlinux xterm gettext

CMD playonlinux

Command to run PlayOnLinux image:

# folder on host to store settings and installations
mkdir -p ~/winehome
# allow X access for user in container
xhost +SI:localuser:$(id -un)
docker run --rm \
    --env DISPLAY=$DISPLAY \
    --user=$(id -u):$(id -g) \
    --env USER=$(id -un) \
    --volume /tmp/.X11-unix:/tmp/.X11-unix \
    --volume ~/winehome:/home/$(id -un) \
    --env HOME=/home/$(id -un) \
    --ipc=host \
    playonlinuximage


How hard is it to hack into a webmail account with a strong 8 character password?

"Eight digits" means 108 = a hundred million possible passwords. At best, you selected your password fully randomly, implying that the attacker, on average, will have to try half of them before hitting the right one (so fifty million connection attempts).

(The "at best" means here that the attacker always has the option of trying passwords in a random order, so there is no password selection strategy, however nifty it may look, that can make things harder than that for the attacker. Some selection strategies may make things easier, though. Therefore, in password generation, randomness rules.)

The important term above is "average". On any specific case, an attacker may get especially lucky or especially unlucky. However, the attacker can perform the same kind of computations and will decide to attack or not to attack based on his perceived, a priori chances of success. Also, not all attackers are completely rational in their decision-making.

How many authentications the attacker may attempt depends on the context and server behaviour. If the server uses "typical" hardware, implements inexpensive password processing (e.g. single SHA-1, not bcrypt), and does not limit authentication rates, then an attacker can hope for, say, 1000 authentication attempts per second, thus reaching the 50 millions in about 50000 seconds, i.e. about 14 hours. On the other hand, if the server locks out the account after 10 failed successive authentication attempts, then the attacker won't be able to try more than 9 attempts between any time you connect; if you connect on a daily basis, then the attacker's expected breaking time will be about 15210 years.

Since there is a lot of variation in how servers implement authentication, and in particular how hard they try to detect brute force attempts and how thoroughly they react to it, the only possible answer to your question can only be "it depends".


Remember me vs. persistent session for web applications

The main risk of a persistent session is increased exposure for any existing client-side vulnerabilities (e.g. XSS, CSRF, session fixation, etc).

That is, any malicious site targeting your users through exploits for the above would be more likely to succeed because the user is left logged in.

With remember-me the above could apply too - Say the long-term remember-me token is exchanged for a session token automatically per request.

e.g.

in the request the browser sends

Cookie: remember-me=32132213312132

and the server automatically issues a session token for this request because the token validates. It also replies with their new session token for subsequent requests to use in this session:

Set-Cookie: session=asdkalkjdjsaddsajdsal

This shows that even though a separate cookie is used for long term access, because it is automatically exchanged it will also aid cross-domain exploits in attacking user sessions.

You could mitigate this by using OAuth2 style refresh tokens.
Then if the attacker tries an CSRF attack such as

<img src="https://example.com/transfer_money?to_acc=2321321&amount=1000000" />

it would not automatically succeed because the refresh token alone is not enough to authenticate the request (remember-me) - it must be exchanged for an access token (session).

e.g. if the user visits your site, there could be another explicit step to get the session token to represent an active, logged-in user:

<form method="post">
  <input type="hidden" name="anti-csrf" value="asddadaddasa242421fsas" />
</form>

The anti-csrf token is attached to the refresh token in the server-side database, preventing a CSRF exploit from being used to get the token ahead of the attack. The above should be manually submitted by the user to prevent an attacker from opening the page in a popup or within an IFrame.

Only after all of the above validates does the server reply with an access token (session):

Set-Cookie: session=asdkalkjdjsaddsajdsal

Of course your site should already mitigate against XSS, CSRF and the like, however this is a defence-in-depth approach to guard against long term tokens being set that have a higher chance of compromising a user because their login is more likely to be active should they be attacked.


Why does Antivirus Softwares have an Issue with EXE Packers

Kaspersky and Nod32 have unpackers for them. Some other are just lazy to do so and instead they label it as a hack tool. You can try different packers that they don't detect or just rar your exe instead.


Using MD5 for malware ids: collision attack risks?

A quick analysis:

Threat: Somebody creates a clean file that matches a malicious file's MD5 hash.

Result: The clean file is identified as malicious, but is merely a collision. Another file that does match still exists and will always be identified as the same.

I suppose if this happens, there might be some talk about moving on. My guesses as to why we haven't:

This isn't authenticating malware, but identifying it. Inserting false positive matches has limited value. True positives will still be located.
It is presently universal. One can identify malware with only one hashing algorithm operation. If we change over, you'll have to start hashing every file with multiple algorithms unless somebody keeps a repository and can post new algorithm hashes for everything.

A false match has very limited value in that you can't do much more than try to convince somebody that they're looking at a piece of malicious software that might be a different piece of malicious software... or just a bunch of bits. Only researchers trying to learn about that particular malware could care and they should realize what's going on.

Update

It is my understanding that virus databases do not include "clean" checksums. If there is a matching MD5 entry, it is for something that you don't want on your system unless you're trying to research it. Because a section of an executable can be set aside to be filled with any old nonsense, it is possible to create a malware file which has the same MD5 sum as another innocuous file (a "collision attack").  While we don't know how to do a practical "preimage attack", the design nature of executables makes it reasonably likely that a focused attacker could create an collision attack as described on Wikipedia's MD5 page. Namely, executable structure allows one a lot of flexibility in filling inserting any data of choice that is ignored during execution. Further, one could load an otherwise non-executable file from a launcher allowing modification of any of the leading or trailing data in the file. That provides for the use of generic launchers and exceptionally easy hash collisions as the first and last bytes can be anything at all.

Since databases don't contain clean files, you won't get a false negative. You could get a false positive if somebody engineered a piece of malware with that in mind. If you were in charge of building the first malware database today, you'd use a different hash algorithm. For historical reasons and a relatively low impact of a successful collision attack, MD5 continues to march on, though it is not ideal now.


Calling JavaScript functions from within a Style tag XSS

An expression() must be a JavaScript expression. You have two statements, a function declaration followed by an assignment expression. Doing it with a single function expression works for me:

<div style="xss:expression(onload=function() {
    var newInclude = document.createElement('script');
    newInclude.src = 'src.js';
    document.body.appendChild(newInclude);
})">

(although I'm slightly surprised that it does without any extra layer of CSS \nn escaping!)


Is the OAuth 2 authorization code flow vulnerable to the Confused Deputy Problem?

In Authentication Code grant flow, the auth server will be able to figure out the auth code was provided to a different client than the second client.

To obtain the auth code, below sample request will be issued from the malicious client:

GET /authorize?response_type=code&client_id=<malicious client ID>&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Note the auth server keeps a mapping of auth code and client id as a result of a successful auth code request.

Now the malicious client will serve this auth code to the redirect URI for the second client and the second client will in turn request for an auth token. Sample as below:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Note the client ID and secret is encoded in the Authorization header, as a result, when auth server process such information, it is able to tell whether the client id in the request matches to the client id which the auth code was initially assigned to. In this case there isn't a match, as a result the auth server won't grant access token in response to the request.

In other words, the check for client ID performed by auth server in the backend guarantees that all tokens returned in exchange for the authorization code were issued for your application.


How to go from wifi password to computer access

You're mostly right - and indeed, as default commented, "they" are wrong.

What you might do if you had access to the wifi access point would be to lie to the connected devices and turn something they're doing into a point of entry.

For example you might wait until some specific Web request is made to some very common resources (for instance, the jQuery library scripts on a CDN). Then, provided there wasn't any extra security on the call or on the resource (smart sites employ both), you would "tell" the browser that the site hosting the resource is not the real site, but another that you control. The jQuery library there is a modification of the real one, that also performs several tests in search of vulnerabilities.

It could try and download a corrupt PDF file, or a malicious Windows Shell script, and so on.

If one of the exploits is viable, bam!, you own the target machine.

Otherwise, there are still things that can be done even with a limited access - a very common one is try and "enrich" the connected browsers with crypto-mining scripts, stealing some computing power and electricity to run the calculations required to "create" crypto-coins which are then sent to the attacker.

Also, several resources inside the network are often not protected at all (NAS backups, DLNA players, or even computer shares). The data on those is therefore free for the taking.


SSL/TLS supports authentication of the client with an asymmetric key pair. Since this is SSL, it takes the form of a client certificate. The server requests a certificate during the initial handshake, indicating which root CA the server will use to validate that certificate; the client then sends a certificate to the server. This of course requires the client to actually have a certificate to send.

Usual clients (browsers) and servers support this feature. What the server does with the certificate is entirely up to it. In a Microsoft Active Directory + IIS world, the client certificate, once validated, is mapped to an account through one of several mechanisms (either the certificate itself is already attached to the account in the AD server, or the account name is found as a "User Principal Name" in the client certificate).

@Rook talks about TLS with SRP, which is something completely different: with SRP, client and certificate authenticate each other with a shared secret (a password). There is no certificate anymore, not in the client and neither in the server. This has no equivalent in SSH (there was a patch to SSH for that, but it is not much maintained; it does not map well to account names and authentication as they are usually managed in operating systems). Usual SSL clients and server do not support SRP (but this may come in the future).


Data protection laws and regulation for storing IP addresses for registered users

You should definitely check both European and UK Data protection laws to be sure, but as long as you don't collect and store Personally Identifiable Information (PII), you won't have to really bother with laws and regulations.

More precisely:

  An IP address in isolation is not personal data under the UK Data
  Protection Act, according to the Information Commissioner. But an IP
  address can become personal data when combined with other information
  or when used to build a profile of an individual, even if that
  individual's name is unknown.

So this has to be determined based on the type of information you collect and/or store from your users.

Also, as mentionned into comments this does not seems like the right approach to achieve this.


Why is DARPA interested in secure messaging platform using blockchain technology?

I see your question as having two parts:

Why blockchain?

According to ZDNet's summary of the request, the preference for a decentralised blockchain solution is rooted in an interest in moving away from legacy centralised architectures, which DARPA describes as "expensive, inefficient, brittle and subject to cyber attack" at the given link.

Why not an existing solution?

From my view, DARPA's request for proposal is justified before even assessing the advantages of using a blockchain solution in particular.

After reading the summary by ZDNet, two reasons come to mind:

Specialised requirements: The alternatives you list are for text (and basic attachments) only. By comparison, the linked article refers to planned use for Military Interdepartmental Purchase Requests (MIPR), described here in Oracle documentation. Verging towards a procurement solution, this requirement alone is beyond the capability of what you have listed. Also, without significant redesign, those solutions would not be capable of catering to military user groups and access levels.
Dependency on third parties: More generally, it makes sense for any defense organisation to own the lifecycle of such a critical platform. Hypothetically, if the listed solutions did meet DARPA's requirements, to rely on an existing third-party solution would introduce unnecessary risk (e.g. non-DoD users on the platform, limited or no authority over design decisions, existing solution architecture being unlikely to meet defense standards). Although it is unfeasible to reinvent every technical solution in-house, in this example, little would be saved by relying on the listed alternatives.


Using Keytool to export and change password of certificate in a KeyStore

1- Changing the keystore password:

keytool -storepasswd -new new_storepass -keystore keystore.jks

2- Exporting the certificate:

keytool -export -alias mydomain -file mydomain.crt -keystore keystore.jks

keytool


The sudo command is probably not installed.

apt-get install sudo


SCADA Operating System & Security Exploits

Is there any classification for a specific operating system used for a specific purpose ?

Yes, although SCADA has not quite arrived yet.

Do-178B is a standard used for qualification of system for aerospace. The FAA requires DO-178B compliance for software and systems on commercial aircraft. It is also typically applied to government and commercial satellites. There are operating systems which are DO-178B compliant: GreenHills Integrity-178B RTOS, Wind River VxWorks Cert Platform, HeartOS DO-178B, SYSGO PikeOS, DDC-I Deos, LynuxWorks LynxOS-178.

Theres is also the European Cooperation for Space Standardisation (ECSS). Although ECSS focus more on the process rather than the product.

NIST has a publication Guide to Industrial Control Systems (ICS) Security which says that Industrial Control Systems use "Differing and possibly proprietary operating systems, often without security capabilities built in"

Here are some highlights of vulnerabilities:

"Some ICS operating systems make setting secure passwords difficult, as the password size is very small and the system allows only group passwords at each level of access, not individual passwords."

"Many ICS protocols transmit messages in clear text across the transmission media, making them susceptible to eavesdropping by adversaries."

"Many ICS protocols have no authentication at any level. Without authentication, there is the potential to replay, modify, or spoof data or to spoof devices such as sensors and user identities."

"SCADA and industrial protocols, such as MODBUS/TCP, EtherNet/IP, and DNP318, are critical for communications to most control devices. Unfortunately, these protocols were designed without security built in and do not typically require any authentication to remotely execute commands on a control device."


Does same hash value indicate a valid key?

No, because you don't "hash" a message with a public key. You encrypt a message with a public key.

Furthermore, a message encrypted with the public key will never be identical to a message "encrypted" (e.g. the encryption function applied with the private key) with the private key.

You can't really prove if someone has your public key, because a message encrypted with your public key is indistinguishable from random data. Therefore even if B is in possession of a message that can be successfully decrypted by your private key, it can still be argued that B received this binary blob from a third-party without any knowledge of its purpose.


Is the following set of steps, secure enough, during register and login on my webapp?

Following your lead, I'm just going to list my thoughts:

Make sure the email address isn't already in use
To be clear, the MD5 hashing algorithm doesn't add randomness to anything.  As a result, it isn't really doing a whole lot for you here, other than making it not-immediately-obvious where your salt came from.  I think it would be better to use a CSPRNG to generate your salt than basing it off of user data and running it through MD5.
This is an application nitpick, but it sounds like you are creating the user record (step 2) and then coming back and storing the salt (step 4) and then storing the hashed password (step 8).  There is no reason you can't just do all of that in one insert operation.  You'll get better performance, but most importantly, your code will be simpler and easier to maintain.
To be clear, you don't want to use an encryption method to hash your passwords.  Hashing and encryption are two separate concepts with different preferred algorithms.  Make sure you are hashing: not encrypting.  From what you have written I think that you are on the right page, and are simply using the wrong terminology.  It's an easy mistake to make, but the difference is critical enough that it is worth me pointing this out.
There is no good reason to use two separate encryption algorithms.  The only reason to do such a thing is to make it so that people can't try to brute force your passwords if they find your database.  However, it is a security measure that relies on your source code being kept secret.  Sometimes they both get leaked though.  This step isn't useless, but it also isn't as useful as you might think, and it complicates your code.  If you want a protection like this I would just include a pepper and stick to a single pass of a secure password hashing algorithm.
On login, make sure you only ever return a single, non-descriptive error message to the user "Invalid username/password combination"
Don't do a simple comparison of the hashed password of the user to what comes out of the database (i.e. $hashed_input == $user_hash).  There are some subtle ways in which such a straight-forward comparison can be used by a malicious attacker to help crack passwords.  Some languages have helper methods to facility password hash comparisons.  Use one or find one.

There can be a large number of subtle ways for security bugs to creep in to the login system of an application, which can easily be missed in an overview like this.  Considering that it is the first line of defense of your application, it is important to get user authentication right.  As a result, your best bet is to use a well-tested and well-supported authentication module that already exists, rather than building your own.  If you do decide to stick with writing your own, then you should at least post your code on codereview.stackexchange.net afterward.


Absolutely; they can see every packet going across their network, and analyse and block it as required.

They should draw up a detailed acceptable use policy if they're going to make you use your own machine for work. Check if there is one. If they haven't told you not to tunnel personal traffic back home then they can't really complain if you do it!


What are advantages of malware evolution research?

Researching relationships between malware families is critical because it makes malware identification and clustering easier.

Any single malware sample is rarely totally unique. Just like in non-malicious software development, a new malware sample will typically reuse code and/or techniques from older samples.

Malware researchers can look for these shared elements with signatures. These signatures will cluster (or "group") separate malware samples which have similar characteristics. You could, for example, write signatures to identify samples which contain techniques like DNS Poisoning and Browser Settings Hijacking. You could also write signatures to identify members of a specific malware campaign such as Zeus or Conficker.

Such signatures can (1) be used to protect users, by detecting that a given file contains malware, and (2) be used to track how the malware changes and spreads over time.

This is made possible when researchers understand relationships between malware samples rather than trying to study each sample in isolation.


How can encrypted traffic bypass the Great Firewall of China when it is being blocked?

You might use low-bandwidth sidechannels. For example, one could set up a site offering pictures, and the site could sport a "thumbnail wall". HTTP protocol allows for requesting those thumbnails in any order, which means that using twenty pictures you can encode up to 20! (i.e., around 60 bits) in the request scheme. There is no way of detecting or blocking such a scheme short of computationally unfeasible statistical analyses, proxying with request order randomization, or HUMINT of course.

A more easily detectable scheme, with more bandwidth, allows encoding information in ETag and Proxy headers.

Then, one could try more cloak-and-dagger schemes: for example one could bounce ICMP packets with faked source address against a trusted (by the government) host. This kind of malicious activity is apparently not (yet) deemed dangerous, and several firewalled hosts will blissfully bounce back the ICMP packet towards the apparent source, thereby penetrating the firewall.

Then again, incredibly, the Great Firewall of China doesn't seem to care about spam. You'd be surprised at the quantity of unsolicited commercial emails, often containing bulky images, reaching the rest of the world from China. Probably, any sufficiently asymmetric traffic towards port 25/tcp is considered symptomatic of the presence of a Chinese criminal, and the firewall has other priorities. Thanks to some helpful spammers in Guangdong, I can confirm that sending back up to 1 Kb encrypted, compressed and base64-encoded error messages has no effect whatsoever, and the incoming connection keeps requesting relay for more and more spam, which is accepted (and discarded). This channel appears to be capable of about 64 kbit bidirectional.

All this requires encapsulating VPN traffic into different protocols, similar to what Haystack did. Other solutions exist - e.g. FreeGate -, but of course the more widely known they are, the faster Golden Shield is going to (try to) bust them. Simpler strategies aimed at defeating a firewall could just entail obfuscating an existing protocol using one-time pad and supplying rapidly changing external endpoints (that's what the ultrasurf utility did), and betting that you can come up with more obfuscations, and quicker, than the GFC people can come up with fixes.

The risk there, though, is that the GFC switch from "blacklist" to "whitelist" operation: first mowing down the traffic to manageable sizes, then actively rewriting rather than rerouting all known protocols, enforcing strong grammar checks and anomaly detection. For example, refusing HTTPS and TLS unless you accept a nonmatching, GFC-generated certificate to allow man-in-the-middle SSL decryption (claiming that this "does not limit responsible citizens", unless "they have something to hide"), and otherwise refusing all packets that it does not fully understand. This is more or less an answer to Ai Weiwei's statement, that the only way to control the Internet is to shut it down. And the answer would be "Well then, how about we do just that".


A side channel attack is a classification of attacks and not specific to any one exploit.  Therefore referring to a "side channel attack" could mean any number of threats.  The only side channel attack that I know of involving printers is an acoustic side channel attack.

It is impossible for an attacker to spoof their IP address over the open internet due to the three way handshake:

I don't believe there is any side channel attack involving ip address spoofing...  These two attack patterns are fundamentally disjoint because the network is one channel,  so what is the "side channel" in a spoofing attack?

In terms of local network attacks,  there is the pwnplug.  It is also possible to hack printers and other network hardware using CSRF and this could provide a beachhead into a network.


Information leak from chat group. How do we find out which user is sharing information?

Attempting an 'Andropov' (revealing different information to several people and check what got leaked is said to have been a favourite technique of Y. Andropov) on such a group is impractical. Even if you created new different groups and assigned each user to one, leaking different information from the one supplied or skipping a leak etc. are obvious counterstrategies and the truth would be really slow in coming out.

You might try a countersting - subscribe to your own Telegram group with several fake names and, if possible (I don't know Telegram) ask for some information on specific topics, to establish a pattern. Supply this information to yourself. After a while, subscribe to the Discord channel anonymously and offer the unknown manager a lot of money for a different specific information (say, the dirt about Bill Gates). Then see whether someone asks for that information in the Telegram group. This, too, is obvious enough - but sometimes greedy people don't see the obvious.

Checking registration patterns could offer some valuable insights. I guess that whoever did it at a certain point decided to cheat, and that's when he created the additional accounts to keep his finger in - but they aren't probably very many, as they are paying accounts, are they not? You might try following the money. Or the times of payment. Or the date of account creation. Note that you might now have figured out who the fake account is, while the original account of the culprit was opened before it (i.e. your culprit is John Smith, who created a fake account under Joe Small. And you discovered that Joe Small leaked, and killed that account - but John Smith is still onboard).

The best move however would be to change dissemination strategy. Use a series of one-on-one connections, so that you can discriminate what information goes out.


Changing picture as characters entered into password

There is some information on this defunct page. Apparently, the idea that the "moving picture" is there to distract shoulder surfers is widespread, and wrong. That's not how this picture works; what it does is actually worse, although it proceeds from good intentions.

When you type the password letters, Lotus employs a "fairly complicated" but deterministic algorithm to map the password as entered to a picture; this basically is a hash function with a very small output size (the output is a "value" in the set of possible pictures). It is possible that the said hash function includes some server-specific secret, but it won't matter much. The real point is that, as you observe, when you enter your password you always end up with the same picture for a given password. The good intention is to achieve the two following properties:

Give an early visual warning as to whether the password was entered correctly or not; the user will soon learn the sequence of pictures for his own password, and thus if a picture changes, then the user knows that he typed the wrong key at that point (or possible a few characters before).
An attacker who tries to mimic this login popup and make the user type his password in a fake popup would supposedly find it "difficult" to recompute the pictures and display them correctly.

The second reason is pure baloney, when you think about it: the "complicated algorithm" cannot be kept secret (especially if the fake popup is actually a man-in-the-middle attack and the true popup is used under the covers to get the actual pictures), and making pictures which move on the screen is really easy: that's what 99.9% of the Web is about.

The first reason, however, includes the seeds of destruction: this leaks information on the password. The pictures are on the screen and very visible; quite prominent, even. The "shoulder surfer" can see them from afar. And he can use them to prune out potential passwords. Indeed, if there are four possible pictures, then this leaks 2 bits per character: for an 8-character password, which would have, realistically, about 30 bits of entropy, this is then reduced to a meagre 14 bits.

Indeed, this feature is analogous to a system which would write on the screen, in big letters, and for each password character: "this character is a digit" / "this character is an uppercase letter between A and M" / ...

Therefore, this "picture" system is downright dangerous and should be banned.

As for the password length, the number of characters is very easy to get for the attacker, because each key stroke is highly audible. The shoulder surfer just needs to be within earshot of the victim, and could easily record the sequence with his smartphone to listen it later on, suitable slowed down, and thus obtain the password length. Under these conditions, hiding the length from the user himself is pointless.


The problem is with Windows and scanning the local machine. Nmap on Windows does not work the same way as it does on Linux due to differences in how the NIC is accessed. It is not actually connecting to each port from a separate process, but is connecting to itself. This is why the scan results in all ports being listed, and results in the connection to each port being omitted.

As a test, scan port 8 and 18 (omitted in the scan above). Assuming you originally did a default scan, those ports would not be tested. If you specifically test them, they should show up as 'unknown', too.


How much added security do I really get with a longer key size?

Once you've reached the "cannot break it" zone, increasing the key size does not change security: you cannot be more secure than that. A 128-bit key is already far into the "cannot break it" zone. Larger keys are for marketing people who need to impress gullible buyers, and for military people who must, by statute, make extensive displays of their collective manhood.

(The best marketing managers try to rationalize larger key sizes by talking about quantum computers.)

If you derive a key from a password, and extending the key from 128 to 256 bits changes anything to your security, then you are doing it very wrong.


How to capture wireless data from an intruder using a home router

If you're on a Linux machine, install ettercap and wireshark.

First, find out your netmask (should be 255.255.255.0 for a normal home network). You can do this with ifconfig wlan0|grep Mask|sed s/^.*Mask://)

Then, run:

sudo ettercap -T -M -i wlan0 ARP // // -n 255.255.255.0

If you know the IP of the intruders, you can put it between the first slashes:

sudo ettercap -T -M -i wlan0 ARP /192.168.1.101,192.168.1.102/ // -n 255.255.255.0

(replacing 255.255.255.0 with your netmask)

You may have to wait a bit for it to load. In the meantime, open Wireshark:

Open a new terminal and run gksudo wireshark&. Use the second (wrench) button in the Wireshark menu, set the network interface to wlan0, and start the capture. You should be able to see all the packets in the network (unless you filtered by source IP in ettercap).


How to assess severity/impact of vulnerability

ISO/IEC 27001 and 27002 encompass this quite comprehensively. They tend to be non-specific, but thorough. You'll find useful guidelines in the 27000 series generally.

NIST SP800-30 Guide for Conducting Risk Assessments is perhaps more approachable, I recommend you start there. Then check the NIST SP800 series for additional documents, including at least SP800-115 Technical Guide to Information Security Testing and Assessment.

The ISO/IEC standard documents are not free, you can find copious related documents, including for the British standard (on which these are largely based) BS 7799. The NIST SP800 documents are free.

Some of the answers to this related question may also be useful: Looking for an open risk assessment methodology


Presumably by KVM you mean KVM rather than KVM.

So in this case, you should have a Linux host and N virtual machines, potentially accessible over VNC.

If your Linux host is not trusted, then nobody can save you. So we'll assume network traffic can't be sniffed within the kernel. So in that case, SSH-ing to the server and forwarding the VNC connection over your SSH tunnel effectively encrypts your traffic from the server to your SSH console on your own machine.

While the VNC connection is unencrypted at both ends of the tunnel, the first in is on your own computer (presumably trusted) while the second end is within the kernel on the Linux server (also presumably trusted), and at no point is VNC traffic sent over the network; it stays within the SSH tunnel.


What security technology do I need to protect my SSN database?

HTTPS is only one part of the puzzle - securing the link between webserver and customer's laptop - and to be honest, it is the simplest bit, as web servers and browsers pretty much do this right, however you will need to enforce SSL v3 and approved algorithms.

In addition you will need at a minimum:

authentication to your web application for customers (username/password, token)
session management
validation of input (see questions on SQLi and input validation)
protection of your database (possibly encryption)
controls defined for developers, admins and others who have access
an assessment of resilience - if your customer cannot connect to the EC2 instance, they are DoS'ed


What does "packed file" mean in security?

A packed executable file is one which is compressed. It contains a small amount of uncompressed code which decompresses and executes the main payload. Files are often packed to reduce their overall size. However, this is commonly done by malware authors as well to reduce bandwidth usage and to confuse older antivirus software, so it's become somewhat of a red flag, despite having benign uses. This is compounded by the fact that packers have become less common in general.

Modern large executables typically reduce total size by compressing individual resources (images, audio, misc data, etc.) rather than using a packer to compress the entire thing at once, code and all.


How can I verify if some data is truly the decrypted counterpart of a byte sequence?

That's not possible.

The only known way to check if plaintext and ciphertext match (with a modern algo like AES) is to encrypt/decrypt, and for that the key is necessary. (Even more, there is no known way to decide if the ciphertext really is encrypted data (any data) or just random garbage.)


How Empathy - a messaging program, is storing my passwords

As far as I know, Empathy is using the system's password storage capabilities (GNOME Keyring, KWallet etc.) to store the passwords for your accounts, so you may have to look into specifically how these tools operate. Which of them is actually used depends on what operating system and desktop environment you're running on.


Are prepared statements 100% safe against SQL injection?

Guarantee of 100% safe from SQL injection?  Not going to get it (from me).

In principle, your database (or library in your language that is interacting with the db) could implement prepared statements with bound parameters in an unsafe way susceptible to some sort of advanced attack, say exploiting buffer overflows or having null-terminating characters in user-provided strings, etc.  (You could argue that these types of attacks should not be called SQL injection as they are fundamentally different; but that's just semantics).

I have never heard of any of these attacks on prepared statements on real databases in the field and strongly suggest using bound parameters to prevent SQL injection.  Without bound parameters or input sanitation, its trivial to do SQL injection.  With only input sanitation, its quite often possible to find an obscure loophole around the sanitation.

With bound parameters, your SQL query execution plan is figured out ahead of time without relying on user input, which should make SQL injection not possible (as any inserted quotes, comment symbols, etc are only inserted within the already compiled SQL statement).

The only argument against using prepared statements is you want your database to optimize your execution plans depending on the actual query.  Most databases when given the full query are smart enough to do an optimal execution plan; e.g., if the query returns a large percentage of the table, it would want to walk through the entire table to find matches; while if its only going to get a few records you may do an index based search [1].

EDIT:  Responding to two criticisms (that are a tad too long for comments):

First, as others noted yes every relational database supporting prepared statements and bound parameters doesn't necessarily pre-compile the prepared statement without looking at the value of the bound parameters.  Many databases customarily do this, but its also possible for databases to look at the values of the bound parameters when figuring out the execution plan.  This isn't a problem, as the structure of the prepared statement with separated bound parameters, makes it easy for the database to cleanly differentiate the SQL statement (including SQL keywords) from data in bound parameters (where nothing in a bound parameter will be interpreted as an SQL keyword).  This is not possible when constructing SQL statements from string concatenation where variables and SQL keywords would get intermixed.

Second, as the other answer points out, using bound parameters when calling an SQL statement at one point in a program will safely prevent SQL injection when making that top-level call.  However, if you have SQL injection vulnerabilities elsewhere in the application (e.g., in user-defined functions you stored and run in your database that you unsafely wrote to construct SQL queries by string concatenation).

For example, if in your application you wrote pseudo-code like:

sql_stmt = "SELECT create_new_user(?, ?)"
params = (email_str, hashed_pw_str)
db_conn.execute_with_params(sql_stmt, params)

There can be no SQL injection when running this SQL statement at the application level.  However if the user-defined database function was written unsafely (using PL/pgSQL syntax):

CREATE FUNCTION create_new_user(email_str, hashed_pw_str) RETURNS VOID AS
$$
DECLARE
   sql_str TEXT;
BEGIN
     sql_str := 'INSERT INTO users VALUES (' || email_str || ', ' || hashed_pw_str || ');'
     EXECUTE sql_str;
END;
$$
LANGUAGE plpgsql;

then you would be vulnerable to SQL injection attacks, because it executes an SQL statement constructed via string concatenation that mixes the SQL statement with strings containing the values of user defined variables.

That said unless you were trying to be unsafe (constructing SQL statements via string concatenation), it would be more natural to write the user-defined in a safe way like:

CREATE FUNCTION create_new_user(email_str, hashed_pw_str) RETURNS VOID AS
$$
BEGIN
     INSERT INTO users VALUES (email_str, hashed_pw_str);
END;
$$
LANGUAGE plpgsql;

Further, if you really felt the need to compose an SQL statement from a string in a user defined function, you can still separate data variables from the SQL statement in the same way as stored_procedures/bound parameters even within a user defined function.  For example in PL/pgSQL:

CREATE FUNCTION create_new_user(email_str, hashed_pw_str) RETURNS VOID AS
$$
DECLARE
   sql_str TEXT;
BEGIN
     sql_str := 'INSERT INTO users VALUES($1, $2)'
     EXECUTE sql_str USING email_str, hashed_pw_str;
END;
$$
LANGUAGE plpgsql;

So using prepared statements is safe from SQL injection, as long as you aren't just doing unsafe things elsewhere (that is constructing SQL statements by string concatenation).


how to block ip from head or ping or get or post to webserver (using apache and windows)?

You could do a policy based QoS, this allows you to perform rate limiting on particular IP addresses based on a particular policy.  This way, you can allow IP addresses to visit your side, but when they perform a particular action (accessing a certain port, accessing a particular URL...), you'll only allow a limited number of sessions.
It will limit the resources your server allocates to them.  It may be a good thing to look at potential "DoS" protection from your ISP, but that depends on yours and their definition of DoS.  This could be just the "noise" of the Internet.
Also, the ApacheHaus has Mod_evasive for Apache 2.4 on windows, this should allow you to put in some rate limiting as well.


It depends entirely on how your program handles filenames. However, path traversal isn't done with encoding, you actually have to check which directory your file is getting written into.


Secure Software Distribution: Is serving a file through HTTPS good enough?

Concretely, can I put up a file on a server making it accessible through a public HTTPS URL and be sure that it won't be infected by malware by the time it reaches the user?

HTTPS only secures the transport. If this is your only problem then HTTPS is sufficient.

But, HTTPS does not secure the files at the server, nor does it secure the transport to the server (unless you use HTTPS too or for similar security SSH). It does also not protect your computer so it might be possible that the binary you ship already contains malware (would not be a first).

  If no, what other ways are there to securely distribute software?

A good idea is to start with security es early as possible. I.e. make sure that the build itself is fine (no malware on your machine, source code not compromised by including suspicious third party code...) and then sign the binary, see Wikipedia on Code Signing. If any changes are done to the software after the signing process the signature will be invalid.


What you describe is https with self-signed certificates, i.e.

  Setup a new server with SSH, it makes it's own keys.

Setup a https server with a self-signed certificate.

  ssh to a new server and get a new fingerprint: "This is new, accept?"

Connect to the new server with the browser. You get a warning but can tell he browser to add an exception.

  ssh to a known server with a different fingerprint: "Something is wrong!"

Connect again with the browser. It will tell you that something is wrong because the exception does not match any more. If you've used HSTS then you would not even have an option to override.

In both case the second step is the critical one, i.e. you should only accept the certificate from the server if you've verified the fingerprint and you've got the correct fingerprint in a secure way (maybe while setting up the server).


For a web application, an acceptable solution for secure communication is HTTPS (tranport level).

It is only acceptable if it provides adequate security for the application. It might be the case if you're talking about a control channel but it might be insufficient if you're exchanging messages (these are just examples, there are many other possible cases).

  In my eyes, the reverse proxy has the same position as the SOAP message router.

That is incorrect: a reverse proxy will see the raw, unencrypted traffic between the endpoints and everything that happens "behind" it will also have access to the messages cleartext. Using SOAP encryption you can preserve all the benefits of using a reverse proxy while maintaining end-to-end message security.

  In this case, why would there be stronger security expectations to SOAP web services ? Or am I wrong and has my vision of web application architecture a weak security?

It's not a question that can be answer in general: the type (and level) of security that is required will depends on what the application is doing.

One important different between using HTTPS security only or SOAP security is that you can maintain the security of the SOAP message much monger and further away than simply the TCP connection. You can save the SOAP message to a database directly and it will still retain all its security properties.


Is an option tag that can have any inner HTML value inserted into it XSS-able?

Yes:

</option></select><img src=no onerror=alert(1)>

There are some tags in which tags are not parsed (textarea or title would be two other examples), but an attacker can of course just break out of those contexts.

The injection takes place inside a normal HTML context,so HTML encoding dangerous characters - < and > would be enough, but it is good practice to encode ' and " as well - is the correct solution here.


Method for securely removing files from a solid state drive

It is not necessarily a secure idea. Solid state drives have what is called overprovisioning space, which is a small amount of space that is accessible only to the hard drive firmware (FTL, or Flash Translation Layer), and is used for wear leveling. This means that, even when your hard drive shows 100% usage, there is still some amount which is unused. The specific sectors which are unused are randomly chosen by the FTL. Unfortunately, this also means that your master key as stored in the encryption header (e.g. your LUKS or TrueCrypt header) may not be wiped, even after you re-encrypt the whole drive. As a result, you would have to wipe the drive many times over and over, and even then, the chance that any given sector is erased is not guaranteed, it is only an increasing probability.

Solid state drives are notorious for hiding control from the operating system. You may be able to get a new open channel SSD, which is a type of SSD without an FTL (or with an extremely limited one) which defers things like wear leveling to the kernel. You may be able to tell the SSD to erase all sectors, and it will actually obey.

Many modern SSDs are support SED, which is hardware encryption used for the purpose of being able to quickly erase the drive. When you issue the ATA Security Erase command, instead of slowly wiping the whole drive, these SED drives simply wipe the encryption key (which is stored in a special area of the drive not subject to wear leveling), rendering all the data on the drive useless). Obviously the key does not provide data at rest security, as it is only used to wipe data more quickly than it could have otherwise. You can use the hdparm tool to check if your SSD supports SED. Run "hdparm -I /dev/sdX | grep 'min for'", with X being the SSD's label. If the number of minutes is very small for either of the options it displays (usually 2, I believe), then your drive supports SED.

If your drive does not support SED, and you do not have a hard disk drive which you could store a key on that you could wipe directly when you want to erase the SSD, you could try to implement a sort of poor-man's SED in a hackish way using NVRAM. On most motherboards, your CMOS RAM (also called NVRAM) is a small amount of non-volatile memory, or sometimes EEPROM, which contains BIOS configuration information. It can be exported to /dev/nvram when the nvram module is loaded. It's usually 144 bytes in size (if it's exactly that size, it means it is NVRAM. If it is larger, it means it is probably EEPROM), but the majority of it is unused. If you can identify the unused portions, which is possible with some tools, or by understanding the format, you can write to it directly at /dev/nvram. Because this area is battery-backed by the CMOS battery (that little button battery on your motherboard that also powers the RTC), it persists across reboots. But because it's not flash, it can be erased instantly and securely. You can easily store a 128 or 256 bit key in there, which could added to your own encryption key to encrypt your main SSD partition. If you ever need to erase it completely, you can just erase the key in /dev/nvram, and it would render data on the SSD inaccessible.

The moral of the story is: FTL is a bitch. Don't trust SSDs, they hide things from you.


password strength audits and mitigations

Yes, regularly. For many of my clients we create policies that require at least annual audits of passwords across all devices, including Windows AD, that tests accounts against the top 500 most popular passwords (and also a list of password derived from their names etc. using various encodings). Accounts in non compliance are marked as having to change at the next login and the users are reminded of the password strength policy.

Management in all case have understood the risks of not checking for this kind of weak password and has been supportive. Given that the number of violations almost always decreases year on year the 'sell' to management seems to get easier.


Does an exposed XMLRPC API in a web application pose a threat?

Well, the first thing that comes to mind is that if you remove an external endpoint of an API that an application relies on, then yeah, it would probably break. :)

More specifically it really depends on the application in question. If it only works over XMLRPC and it needs to connect from a different machine, then yes it will break if you remove the access. Otherwise it might not. The fact that it is publically accessible does increase the risk to your server(s) because of an increased attack surface, but if it's a properly secured service then there is less risk. There is still an increased attack surface though.

However, since it is XMLRPC, which is an antiquated protocol (a precursor to SOAP), there is a good chance that it wasn't necessarily designed with security in mind.

Removing the API would not be security by obscurity unless there is another way to access the API whose protection hinges on the fact that XMLRPC was the only known public endpoint.


Can a 3rd-party iOS 12 app use any of the cameras without the user being aware?

The answer is yes they can (at least for the front and back facing cameras), but that goes against Apple’s App Store review guidelines.

https://developer.apple.com/app-store/review/guidelines/

  2.5.14 Apps must request explicit user consent and provide a clear visual indication when recording, logging, or otherwise making a record of user activity. This includes any use of the device camera, microphone, or other user inputs.

I’m not sure exactly what sensor data is returned by the Face ID API, but I assume that data can also be collected without notifying the user (assuming it has permission to access Face ID).

So the answer is yes they can, as long as they don’t get caught by Apple.


Which KEK can wrap AES, RSA and ECDSA keys securely?

Keys are not so special that they need special ways of encrypting them. Any key that's secure enough to encrypt data for your needs is secure enough if that data happens to be, or include, another key.

Compliance is another matter. Compliance rules sometimes require a key encryption to be at least as strong as the wrapped key, even if you don't need the result to be that strong. But if such rules apply to you, you have to look up their definition of strength, because there's no universal definition. https://www.keylength.com/ lists a few.

For example, RSA-4096 is usually estimated at somewhat over 128 bits, because it would take a little somewhat more computation effort to brute-force an RSA-4096 key than an AES-128 key. In terms of security, the exact number is irrelevant because it's more than what even the largest nation-state can do even given physically-realistic but economically-unrealistic power. That's as long as there are no game-changing advances such as one that quantum computers may bring, but if there are game-changing advances, they'll affect different key types differently anyway, so the relative scale of the numbers would be completely different. So in terms of security, it's perfectly fine to encrypt an RSA-4096 key with an AES-128 key. But in terms of compliance, if you do this, depending on the compliance framework, you may either find that it caps your system's security at 128 bits (which is fine, you couldn't expect anything more) or that it's forbidden because RSA-4096 is somehow too strong for AES-128.

AES-256 should be fine to encrypt anything, even in the strictest compliance frameworks (apart from the ones that don't accept AES, e.g. that want Russian or Chinese algorithms instead). It's not as if there was anything that's stronger on paper.


How does a shared vault in password managers such as 1Password work?

Disclosure: I work for 1Password and had a hand to play in the design of exactly what you are asking about.
What you are after is described in more detail in the 1Password Security Design document. I will leave out some details here so that I can focus on the essential part of the question.
1Password works with the notion of vaults, and vaults are what people share. A vault will have a number of items in it. Each vault has its own randomly generated vault key that is created by the users client when the vault is created.
Let's suppose that Alice has created a vault $V$, and the vault key for it is $V_k$. For synching and sharing the encrypted items in the vault are sent to our server. Note that we never have the vault key, so we can't decrypt the items in the vault (or even the name of the vault).
Each individual has a public/private key pair as part of what we call their "personal keyset". So Alice has a public/private key pair which we will call $A_p$ for the public key and $A_s$ for her private key which she keeps secret. Bob will have his public/secret key pair $B_p$ and $B_s$.
The magic of public key encryption is that anyone can use Bob's public key to encrypt something to him, but only Bob, with is access to his secret key can decrypt it. Alice's and Bob's key pairs are generated by the 1Password client running on their own machines when they first set things up so that we never see their private keys. (Their private keys are encrypted with keys derived from the Master Password.)
When Alice shares a vault, say vault $V$ with Bob, she encrypts the vault key $V_k$ for that vault with Bob's public key, $B_p$. Let's call the result of that encryption the message, $m$
$$
m = E_{B_p}(V_k)
$$
Alice's 1Password program running on her machine will then send $m$ up to the server. We can't decrypt $m$ because we don't have Bob's private key, $B_s$. But we can deliver $m$ to Bob the next time his 1Password client connects to the server. We can also allow for Bob to receive the encrypted items of that vault.
Now Bob can use is private key to decrypt $m$
$$
V_k = D_{B_s}(m)
$$
Bob can then decrypt the items in the vault using the vault key, $V_k$. All of the encryption and decryption is happening in Bob's and Alice's 1Password apps running on their machines, and all the server does is pass encrypted objects between them that it, the server, cannot decrypt.


Can another user on the same computer access my accounts if I tick "keep me signed in"?

If by "work account" you mean User Account within Windows, then no. Each user account in Windows (and most other operating systems) has it's own browser data.

The remember me feature relies on the ability to store a secret token in browser data (usually Cookies), so if you switch user accounts (and browser data), then they will not have that remember me token and will therefore not be signed in on your name.

Of course, since these folks have Physical Access, they could probably break into your user account anyway, or steal the secret token. However, this requires a certain level of technical skill.


Why is "hovering over" a link in an email considered safe? Or is it harmful?

One of my employers told us that if we receive a suspicious email with links, we have to hover over the link (to check that it is not spoofed) before clicking it.

When you mouseover a link, the value of the href attribute  is displayed in the status bar. Since this is the link target, it can give you an idea about where the link is going.

  would someone be able to spoof this action and try to do something funny?

Generally, yes. The actual link target can be "spoofed" using Javascript: It is quite common for websites to exchange the href value with another link as soon as the user clicks on it. For example, you can observe this when visiting Google search results. When you mouseover one of the links, it will be displayed as https://security.stackexchange.com/... but as soon as you click it, that event is captured and you visit an intermediate site first (https://www.google.com/url?...) which redirects you to the actual target.

But any well-designed (web-based) mail client will not execute any JS in HTML e-mails. Active script content in e-mails is  dangerous - not only because it potentially results in an XSS flaw in the mail client but because it can also be used to run JS-based exploits against the browser or simply inform the sender that you have opened the mail.

So, if your mail client disallows JS in e-mails -  which it most likely does -  then the link displayed on mouseover is indeed the correct link target. But you should be aware of other attempts to deceive you, such as homograph attacks or an overly long URL that disguises the actual target domain. It's not as easy to analyze an URL in the status bar as it is from looking at it in the address bar. In a more advanced attack, the attacker could also have compromised a legitimate site beforehand (e.g. through a persistend XSS flaw) and you won't be able to tell from the link at all that the site now actually hosts dangerous content.


Is it possible to spoof the last proxy of an X-Forwarded-For Header?

The load balancer sets the 'most recent' part of the header.

As long as you trust the load balancer (and the connection between your server and the load balancer) to set the header as the IP address at the other end of its TCP connection, then you can trust that the last entry in the header is an accurate representation of the source of the connection (from the load balancer's perspective).


How to prevent my MI AIR purifier from listening on my wifi traffic?

Follow the instructions in your router's Users Guide to create a Guest wireless network (Section 4.7 of the user's guide.)  This makes your router advertise a second wireless access point.  Pick a different name for it, such as dharm0us_guest.  Uncheck the box marked "Allow Guests to Access My Local Network".  Pick a password for the guest network that is different from your home network's password.  This essentially creates a DMZ, which is a network isolated from the rest of your home's computers and devices.

Then, reconfigure your Air Purifier to use the newly created Guest network, dharm0us_guest, with the new password.  Now if your Air Purifier is hacked, it won't expose your internal computers to any threats.

Note that if you do this, you won't be able to "locally" control the air purifier with your smartphone app.  Your only access will be via remotely, via their service interface. This may or may not be an issue for you, it's simply a consequence of isolating their device to reduce the risks to your network.

While you're at it, you might also want to follow the user's guide in section 4.9.4 to disable UPnP in your router.  This will prevent these kinds of devices inside your network from opening security holes in your router without your knowledge.


For client redirect : If all domains use https AND HSTS, then the redirect is  as safe as possible.

For server "proxy": If they are on the same server http is probably fine. If they are in the same internal network, http is not a good idea. If internet is between them, http is not safe at all. For https, make sure the servers check the validity of the certificates.