Is the dark web server actually part of surface web?

The dark web is like a lair for hackers/criminals/etc.

That's an oversimplification, but we'll go with it.

  But has anyone, like FBI or CIA ever found the main server of the dark web? Where is the main server located? I thought all Internet data flows are being watched by many government institutes like FBI/CIA. Why have they not chased the main server of the dark web itself?

  I mean the dark web is actually a part of the "healthy"/"surface" web right ? why they did not get caught by the main server provider ?

We apparently need to cover a broad number of basics here.

First, there is no main server of the public web. That is not how the web works. I can't go into that much detail in an SE answer, but your computer generally uses (the distributed) DNS to turn a human-readable hostname into an IP address, and then that gets routed across physical wires based on (again, distributed) routing protocols and data until it gets to the server it's supposed to get to.

The so-called dark web is structured similarly - different people run different web servers, and traffic has to go to the right places. The difference is in how you get there.

There's an anonymizing technology called Tor. When used to connect to the public web, a tor user's traffic goes through three different intermediate servers before trying to get to the requested website. The first node knows who the user is, but not what they were requesting (it's encrypted). The third node knows what's being requested, but not who requested it. And the middle node knows essentially nothing. This process prevents the website and other MitM snoopers like the NSA from knowing who is requesting that website.

(Insert a bunch of caveats here around anonymity with tor, attacks on the protocol, safe browsing, and general advice to please go look up more than this comment before relying on it.)

Tor also provides a feature known as hidden services, where the website operator also sets up a circuit of three nodes to connect to. A tor user's circuit meets up with the website's circuit, and traffic flows through all six of the nodes without anyone knowing who the other parties are. This is how the deep web works.

The only question then is how the two meet up in the first place, and that uses yet another distributed piece of technology, a distributed hash table built into tor. So there's no centralized server to shut down here, either.

The weak point here is that the website operator needs to not leak their identity or the server's location on accident, which can happen through all sorts of misconfiguration or human error. But even if they do, that is only that one site that gets shut down, not some giant shutdown of the network. Also, anonymity is not illegal, so there is no legal reason for the feds to shut down tor overall, even if they could. It in fact started as a US government project to assist people in oppressive regimes.


How does a client know that a DNS zone is DNSSEC protected?

DNSSec does not prevent against MITM attacks. This is also mentioned in the following answer and a bit more explanation of how DNSSec works and some of its limitations.

In this paper author discusses ways to circumvent DNSSec in Section VI, including  'intruder-in-the-middle' attack.


There are lots of vulnerable routers out there which can be easily be hacked. A typical attack exploits that there is no or a known password for the administrative interface or that the user is logged into the router or that some critical pages on the router can be accessed without authorization. The attack itself then can be executed just visiting a web site, where silently a CSRF request to your router, maybe through some advertisement. This is far from new or rare, see this report) about hacking of millions of routers in brazil 3 years ago.

Other attacks exploit the problem that some routers have the administrative interface open to the internet or that the router has backdoors usable from the internet.

For more information see also routersecurity.org.


Yes you could download the image and check the exif data. Some devices store the GPS co-ordinates as far as I know


Wireshark - I can't see traffic of other computer on the same network in promiscuous mode

Wireshark has a setting called "promiscuous mode", but that does not directly enable the functionality on the adapter; rather it starts the PCAP driver in promiscuous mode, i.e. telling it to process packets regardless of their target address if the underlying adapter presents them. This is most noticeable on wired networks that use hubs instead of switches, where in non-promiscuous mode you will see only broadcast traffic and packets unicast to your adapter address, but in promiscuous mode you will see everything - in both cases your adapter is receiving every packet on the network, but in promiscuous mode the PCAP driver doesn't filter out packets not intended for your adapter.

Running a WiFi adapter in promiscuous mode requires some additional work and support by the driver. Normally a driver would implement only the necessary code to receive and process 802.11 frames intended for it to receive. For promiscuous mode to work, the driver must explicitly implement functionality that allows every 802.11 frame associated with the currently connected access point, intended for that receiver or not, to be processed. There's also another mode called "monitor mode" which allows you to receive all 802.11 frames regardless of which AP it came from. Both of these require explicit implementation.

Unfortunately, the devices which implement these are not cheap. At the moment I think only AirPCAP is fully supported for doing this kind of work, and it costs in excess of $500.

It's also worth noting that you can't sniff the network traffic of other users on a network which uses WPA2, as each client exchanges its own session key for encrypting the radio communications between it and the access point. You'll be able to sniff the 802.11 frame headers and some housekeeping packets, but the actual network payloads will be encrypted.


Is supporting older version of Java dangerous

Is there a security risk involved with have the Java 1.7 JDK installed on our build machine if all it is being used for is to compile the jar file?

Probably not, but there's no need to do that: javac provides the -target flag, which allows you to generate classfiles compatible with any version (provided that you don't use source features or call library methods that were not supported by that version).

  Are there any major security concerns with supporting Java 1.7 when it is being used as a wrapper for a CLI tool?

Probably not. Security concerns with Java generally involve implementation issues in the JVM (Java Virtual Machine) or the libraries that it uses. There are also some issues with third-party libraries that enable exploitable behaviors (for example, Apache Commons Collections supporting a Map implementation that could execute arbitrary code).

If you're simply compiling the same code for different target architectures (1.7 versus 1.8) then you are almost guaranteed to get the same bytecode output. You can compare the bytecode generated for each version with the javap program.

  Does running our library (that uses 1.7) create any security risks if it is being used in a program that is being compiled with Java 1.8 (or the latest version), or does that mitigate the security risks and put in place the security patches of later Java versions?

I can't understand the question that you're asking, so I'll answer the question that I think you're asking: if you run a 1.7-compatible compiled class on an up-to-date 1.8 JVM then you receive all security benefits of that JVM. If running on a 1.7 JVM or an older 1.8 JVM you are subject to whatever security flaws were present in that VM.

Note that many open source libraries are targeted to 1.6 and even 1.5. The only real reason to target a newer version is if you use language features (eg, Lambdas) or library functions that weren't available in the earlier release. In that case, picking the minimum necessary target version will prevent an earlier installation from compiling with the class, because each Java version uses a different classfile version and older compilers won't accept newer files.


What options exist for authenticated full-disk encryption?

From your example, I think the answer is pretty straightforward. I think there are several ways to do it depending on your preferred workflow but the simplest is probably...

When you update the image, take a hash of the image before uploading it. Then, when you download it, check the hash before use.

Of course, that is only reasonable if you don't update the image that often. Otherwise, you need to automate the workflow.

More specifics depend on what OS you are using the image on. The good news is that, since you have control of the hash, you probably don't need to worry too much about which hashing algorithm you use. Some have known flaws but I think that, in this case, that probably won't worry you too much.

You could go further and digitally sign the image and there are certainly tools that will do this for you. Have a look at some of the forensic disk copiers. Using such a tool will give you a very high degree of confidence that the data has not been altered.


You will have to weigh decisionmaker risk tolerance against your overall business loss exceedance, typically both on curves of the same graph.

What is at risk (tell the CFO and CEO that what's at stake is the top-line of the company -- it's entire sales and all of its growth capabilities)? What will cost extra to manage installs and centralize Domain Administration as opposed to allowing willy-nilly admin access? If your company makes under $100M per year, then you are already fortunate to be running at a Active Directory domain functional level of Server 2012 R2 (which allows Protected Users) and utilizing the amazing security protections that default in Windows 10 client infrastructure. You could also stand to gain some advantages by adding SysMon and EMET log streaming to a centralized log infrastructure (a free one named MozDef, which runs on Linux, comes to mind but there are also free AutoRuns and SysMon Windows-based services). However, Windows 10 is so strong, it would only need EMET for the event-log capabilities.

Try to upgrade everything to Powershell v5, if not already. Windows 10 gives many advantages with Powershell v5 as well, but these advantages can work against you. Consider implementing AppLocker in any form (even as strong as whitelisting everything -- but you'll likely want to blacklist a few things, at least occasionally) which, when combined with Powershell v5, has Script Block Logging, Protected Event Logging, and Antimalware Scan Interface Integration  (AMSI). Please enable all of these -- they're free wins. If you really want to go crazy, get the Microsoft Advanced Threat Analytics platform. Do not loosen UAC policies, but ensure that servers have full/max UAC for any accounts used on them. Domain Administrator is very dangerous -- use Protected Users and mark these up with full UAC. Protected Users should only be able to log into servers and regular users only into their workstations (possibly by OU or however you categorize).

If decisionmakers can live with a 1 percent chance per year of losing anywhere from $5M to $75M, then you'll be fine with a few free tools, at least until you can prove out your program. I don't see any reason for you to provide any extraneous admin access to anyone (not even local). Have one or two sets of Forest/Domain Administrator accounts (never use them except in emergency, make their passphrases 30 characters long, safely print them, and then store in fire safe or two), and a few Protected Users (for those who need server or domain-change access).

If your time and the company's resources are better spent elsewhere, then don't do any of this. It's really unlikely you'll be compromised if you indeed have only Windows Server 2012 R2 with a domain functional level of the same and all clients are Windows 10. One XP machine can mess this all up, though. One user with local admin or domain admin privileges can completely mess this up. Your consultant is right to tell you that handing out admin accounts willy-nilly is weak form.

My suggestion is to grab the book Windows PowerShell in 24 Hours, Sams Teach Yourself and use its guide to install OneGet, Chocolately, and ChocolatelyGUI. Then you can use your powers as admin to make installs and upgrades of applications very easy for everyone. Another alternative is to get the book Learning Puppet for Windows Server, but this will require a Linux server for the Puppet components. Using Foreman (a web UI for Puppet), you can setup normal users with just enough access on Foreman to install apps to their PCs. This way, you do so through the Puppet agents and not through admin accounts.

When you log in to a computer as Domain Admin on console, through runas, or via RDP you are severely degrading the ability of each system to defend its registry, especially the Security (especially Policy Secrets) and System hives. Attackers use tools such as mimikatz to access these hives, but can also pull tokens out of running processes to impersonate Domain Admins. The best way to avoid running as Domain Admin is to use the Protected Users, as well as either WMI (through wmic) or PS Remoting to make changes, install things, et al.

Your job is to enable the business by protecting it. You are being challenged by people very skilled at negotiation -- so you have to understand it's a little give and a little take. What you can't allow to be taken is control of admin rights -- i.e., privileged-account management. You could show them that you could do so if you were given an allowance to purchase all of the solutions from CyberArk, BeyondTrust, Varonis, and STEALTHbits, but that a typical integration of those four solution sets costs around $10M. Instead, offer to solve the problem by providing better-quality service from yourself regarding changes and installs. If you can automate this via Chocolately (or OneGet) and/or productize installs through Foreman, then you are really seeing win-win with your C-levels. This is known in negotiation as a BATNA. If all else fails, tell them that by giving away admin access, the 1 percent per year for a loss of $5M to $75M still applies but that they are adding a separate other 10 percent per year for a loss of $10M. See if they like those numbers and want you to give up access still. They'll probably ask where you're getting those numbers from. Tell them howtomeasureanything.com/cybersecurity

A lot of my answer comes from the information culled out of this slide deck -- http://www.info-assure.co.uk/public_downloads/Talk%20is%20cheap-IR%20tools%20can%20be%20too.pdf


Is CSRF possible if I don't even use cookies?

No you are not vulnerable in that scenario.

The reason is exactly as you explain - a third-party site could generate a request to your site, but the authentication details will not be attached.


Can a VPN client install a CA Root Certificate for use in the web browser?

Any process running with our privileges our higher can in theory install a new root certificate. But that does not mean that it will do it. If you take for example the VPN support bundled into Windows (PPTP, L2TP/IPSec) then there is no way for the server to push a new root certificate to your system. The same is true with the original OpenVPN client.

But, if your VPN provider asks you to install specific software to use their VPN then it might be possible that this software will already install a new root CA when you install the software or that it will do it later when instructed by the VPN server. Or it might do even worse things.

VPN software is in this case no different from all the other software you download and install to your system: it can do a lot of harm (adding a new root CA, monitoring you through your webcam, capture all your keystrokes...) and you should install it only if you really trust the vendor and the path how the software gets distributed.


ENCASE Forensic: Detect if someone ran CCleaner or CleanUp software

You could look through either the UserAssist registry entries for each user (located in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist), or check the prefetch files (located at %SystemRoot%\Prefetch).

Both maintain a list of run programs on the machine including the last time they were run and the number of times said program was run.

Further reading:

Prefetch
UserAssist


How could a server to server rest api communication be more secure, by using OAuth 2?

There can be multiple reasons for this depending on how the services are generally deployed in the organization/system and what is the typical authentication mechanism. It would be weird to use a different authentication mechanism just for one service.
If one had to make a blanket statement, then I think the advantage is in terms of token expiration. The API keys have no expiration date while the OAuth tokens generally do. This way, even if some rogue server in your system was able to grab your OAuth token, there will be a limited amount of time till they are able to authenticate.


How do "Confidence images" on my bank's login page improve security?

You are describing a variation of SiteKey.

Your bank implements it incorrectly because it asks for both username and password before showing the image. If the page were an attacker's he couldn't show you the correct image, but that doesn't matter because he already has your username and password.

If correctly implemented, it is still greatly ineffective.


Securely opening an insecure webserver to a single phone

A few ways.

Option 1:

A proxy server with authentication.

Phone -> proxy (check auth like basic auth if using https proxy, if not https proxy then no real security gain) -> internal-web-server

We use these in corporations. You set an automatic proxy file (pac) on your phone to route requests to your domain web page through the proxy and the rest direct.

But proxy on cellular is tough.

Option 2:

Setup nginx with reverse proxy settings, and https, and require basic auth. Then you'd not need to mess with pac files.

Option 3: install openvpn on the server and the client on your phone.

Option 4: install an ssh client on your phone, ssh to your home server and forward the web port.

Good luck


Is it worth using ModSecurity on a single entry point websocket connection?

As of 2017, ModSecurity does not support and does not plan to support WebSockets, as stated by Spiderlabs development team:

  Currently ModSecurity is not capable to inspect WebSockets. It is only capable to understand the http requests.

So, not only it will not be helpful, but it may even have unexpected side effects making your application unreliable.


If someone bought the .local TLD could that be a security risk?

To answer your specific question, .local has already been reserved by ICANN as an internal gTLD.  Please see section 2.2.1.2.1 "Reserved Names" in the ICANN Applicant Guidebook.

The full list of reserved gTLDs are:

AFRINIC  IANA-SERVERS  NRO   ALAC  ICANN  RFC-EDITOR   APNIC  IESG  RIPE  ARIN
IETF  ROOT-SERVERS  ASO  INTERNIC  RSSAC  CCNSO  INVALID  SSAC  EXAMPLE*  IRTF
TEST*  GAC  ISTF  TLD  GNSO  LACNIC  WHOIS  GTLD-SERVERS  LOCAL  WWW  IAB
LOCALHOST  IANA  NIC

*Note that in addition to the above strings, ICANN will reserve translations of the terms
"test" and "example" in multiple languages. The remainder of the strings are reserved
only in the form included above

(There is an addendum to the above to state that "similarity" metrics are applied to make sure that gTLDs like .1ocal are not abused, either.)


How to test ldap that authenticates with kerberos

There are two possible authentication methods here:

"Fake" Kerberos, where the LDAP server receives a plain password and checks it by attempting to obtain a TGT using that password. For this to work with OpenLDAP, you need:

The userPassword attribute must be set to the special value {SASL}user@REALM (with the actual Kerberos principal of course). The text after {SASL} is the username that OpenLDAP will give to libsasl, along with the received password.
libsasl must be configured to use saslauthd as the password check mechanism, by putting the following in /usr/lib/sasl2/slapd.conf:

pwcheck_method: saslauthd

And another line to make it offer the SASL PLAIN mechanism:

mech_list: plain

On the same server, the saslauthd daemon must be running (it is part of libsasl; usually the "cyrus-sasl" or "sasl2-bin" package). This daemon performs the actual password verification on behalf of OpenLDAP or other servers.
The saslauthd daemon must also be configured to use Kerberos 5 using ‑a kerberos5 as a command-line option.

With this, you should be able to use your Kerberos password with a simple bind (ldapsearch ‑x ‑D ... ‑W) or a SASL PLAIN bind (ldapsearch ‑Y PLAIN). It is however still "fake", as it doesn't take advantage of Kerberos features for protecting the password over the network.
"Real" Kerberos, where the LDAP server receives a Kerberos ticket and checks it against the local keytab, without having to ever reveal the password. For this to work with OpenLDAP, you need:

The system keytab must have keys for the ldap/fqdn@REALM principal, where fqdn must match the reverse-DNS of the server's IP address. You can use the ktadd command in kadmin to extract keys into a keytab.
The keytab must also be accessible by OpenLDAP (usually the ldap or slapd account). (If necessary, you can use a separate keytab file from the system one; in this case, OpenLDAP must have the $KRB5_KTNAME environment variable pointing to the dedicated keytab.)
libsasl on the server must be configured to offer the GSSAPI and/or GS2-KRB5 mechanisms. This is usually the default, but you might need to put the following in /usr/lib/sasl2/slapd.conf:

mech_list: gs2-krb5 gssapi plain

Since there is no password checking on the server, saslauthd is optional.

With this, you should be able to kinit on a client, and use the obtained ticket with SASL GSSAPI bind (ldapsearch -Y GS2-KRB5 or ldapsearch -Y GSSAPI).


How to store encrypted confidential user information in the database, which will need to be decrypted at runtime?

This is one situation where using a KEK (Key Encrypting Key) and multiple DEKs (Data Encrypting Keys) comes in useful.  (Background question here).

What you would do is encrypt each client's key (these will be the DEKs) using the KEK.  The DEKs are stored (encrypted) in the database.  When the application starts up, it uses the KEK (which is not stored in the database) to decrypt the DEKs, then the (decrypted) DEKs (which exist decrypted in the App, not in the Database) to perform crypto operations.  When the App shuts down the DEKs are all safely encrypted in the database, waiting for the KEK to unlock them again.

This model can allow you to separate the keys (DEKs in the database, KEK on an application server file), to require manual intervention (KEK provided to App at start-up time), or to rely on an HSM for the KEK.  All of these provide more security than simply stuffing client DEKs into the database without protection.


Which specification does Java HostnameVerifier come from?

The HostnameVerifier interface is specific for Java, i.e. the interface itself does not follow any standards except the specification of Java. The actual implementation of the hostname verification should though follow established standards.

How a hostname verification should be done when checking the server certificate of a TLS connection is mainly defined in RFC 6125 for various TLS based protocols in general and specifically for HTTPS in the older RFC 2818. While there are in theory differences between various TLS using protocols (HTTPS, IMAPS, POP3S, LDAPS...)  specifically regarding the use of wildcards most implementations ignore these differences and just implement the way the verification is done in HTTPS.

Apart from RFC 6125 also the CA/Browser forum requirements are relevant. But these are usually only implement fully in the browsers, most programming language don't care about things like Public Suffix lists and their relation to wildcard checking.


How long to crack an 8 character WPA2 hash if first char is known

If the passphrase is exactly 8 characters long and the first character is known, then only 7 need to be brute forced. Assuming characters are 0‒9 and A‒Z, the maximum number of combinations is 367.

An AMD Radeon RX480 GPU can go through approximately 170,000 candidate WPA2 passwords per second. This means it will take around 367 / 170000 seconds at most to exhaust all possible 7 character upper alphanumeric passwords, and half that on average. This equates to an average of 2.5 days.

Note that higher-end GPUs and clusters of GPUs can crack such a password, and stronger ones, much more quickly. From Twitter, 8x 2080Ti GPUs can crack any 8 character password in ~2.5 hours!


Despite what you may think, you actually were using HTTPS.  This is perhaps an over-simplification, but here's more or less what happened:

When you accessed the website with http:// as the protocol in your Address Bar, you effectively told your computer "Make a request for this webpage, from this server, and send that request to port 80 on the server".  If the server is configured to allow access via plain HTTP (apparently, it was), the server will respond and your session (unless re-directed) will continue over HTTP.

By changing the protocol to https://, you instead directed your computer to attempt an SSL/TLS handshake via port 443 on the server and then send the HTTP requests through that tunnel.  Obviously, this worked or you would not have been able to access the page.  Since the SSL/TLS connection was successful, that meant that all subsequent HTTP requests sent through that tunnel would be secured from casual eavesdropping (e.g.: via Wireshark).

But now, you ask, what about that nasty red slash through https, and the "x" on the lock?  These indicators do not mean that the SSL/TLS connection was unsuccessful, or that your communications to the website are not encrypted.  All these negative indicators mean is that the website is not signed by an authority your browser recognizes.  This is often the case for the web interfaces on SOHO networked equipment, business applications, or websites where the administrator has chosen to use a self-signed certificate instead of purchasing one from a well-recognized authority (e.g.: VeriSign).

This is analogous in some ways to selling alcohol in a jurisdiction where such sales are age-restricted.  Since I don't know all the intricacies of the real-world laws, let's say for the sake of argument that the law only goes so far as to say it is illegal to sell alcohol to a person who is younger than a given age.  What the law in this hypothetical case does not specify is whether you are required to check I.D. prior to a sale, or which forms of I.D. are considered to be valid proofs of age at time of sale.  Authoritative proof of the buyer's age is only ultimately required in court if the legality of the sale is ever challenged.  However, it is still of course a good idea to check I.D.s on every sale just to be safe.

Here, you are a clerk at a convenience store in the great state of Comodo.  Most of your customers will be fellow Comodoans, and so you are naturally able to easily recognize and verify their I.D.s which are issued by the Comodo Government.

One day though, you get a customer from the distant state of VeriSign.  What do you do now?  Fortunately, your store has a book called Trusted Root Certificates which has pictures and tips on how to verify I.D.s issued from various states in your country.  You check your book, compare the customer's I.D. to the relevant photograph and notes, and judge that the I.D. is indeed issued by an authority trusted by your store.  Given this, you can now trust that the information on the I.D. (particularly, stating the customers identity and age) is accurate, and therefore be comfortable in knowing that you are making a legal sale.

On another day, a customer comes in from overseas.  His name is Drupal, and he hails from the land of DigiNotar.  He says he is old enough to buy alcohol, and his DigiNotarian Government I.D. concurs with his statement.  However, your Trusted Root Certificates book does not have any information to help you verify an I.D. from his country.  What do you do here?

Strictly speaking, by the letter of the law in this hypothetical country, your sale would still be legal if your customer is in fact as old as he says he is.  You could choose to assume he is telling the truth and, if he actually is, go on with your life without ever being convicted of any crime related to that action.

But, without any documentation from an authority you recognize, you are still taking the risk that he is not telling the truth.  It's very possible that he is not of the proper age, despite what he and his I.D. may claim.  In this case, the sale will still be completed.  The product will still only be transferred between you and your customer (not immediately available to anyone else, unless your customer chooses to distribute it), but now the problem is that the alcohol has been given to someone who legally should not have it - and you could be in trouble for this.

TL;DR:  As long as your browser shows https:// as the protocol, you can be assured that the data in your communications are secured between your computer and some endpoint.  If there's any warning signs around that https:// area though, that means that the browser does not trust that endpoint to be what it claims to be.  It is then up to you to decide whether you trust the endpoint's claims to identity enough to transfer sensitive data over the connection.  The connection is still secure in the sense that nobody between you and the other end of the HTTPS connection can sniff the data, but you are taking the chance that the other end isn't what it claims to be.

UPDATE: Some browsers are now beginning to incorporate checks on the cipher suites and other properties of the HTTPS connection, and providing warnings accordingly. In these cases, the above still applies, but you should be aware that it will be easier for an eavesdropper or Man-in-the-Middle to break that security than if the site used stronger encryption protocols.


How can I determine if my system was infected?

Unfortunately, we can't be 100% certain your computer is safe after opening a probably infected file. It seems that multiple security products flagged this .xlsx file as potential malware according to Virus Total report, I doubt this is a false-positive.

However, the risks might be mitigated since you are running on Linux and with Libre-office. The probabilities that the malware might have been made to run on Windows with Microsoft Office is higher.

In paranoid mode, if you want to be more than 95% certain than no malware is left on your computer, I would recommend you the following :

1) Backup all your files (except the malware-bundled .xlsx one) from a clean OS instance.
   - A Linux Live CD burned from a trusted computer would be the best

2) Completely wipe your computer hard disks, using a software such as DBAN.
   - If you want to go faster, I suggest you use dd from the Linux Live CD.
     dd if=/dev/zero of=[your hard disk] bs=4M count=256
     (writing 1 GB of zeros should be enough to clear the MBR/GPT of unwanted stuff, in case you got a tough malware)

3) Reinstall your OS, be sure your installation media comes from a trusted source.

4) Reinstall your program, again, be sure installer is from a trusted source.

5) Restore your data


This has already been asked and answered (partly) in a previous stack-exchange article. It's a simple configuration change so save a copy of every printed document. You will need to make sure you have a great deal of storage available before you enable that.

The problem is not saving the documents and knowing what was printed and when, that's very easy, the problem is using the information pro-actively. Generally this information is used to re-construct events after the fact.


Can Hash Length Extension attacks be avoided by changing the data structure?

Let formalize the secret in the middle as;
signature = Hash( m[1..l/2] || secret || m[l/2+1..l] )

where l = len(m). This construction is not differ from the original H(k,m) since simply consider that k = m[1..l/2] || secret and then apply the length extension attack, success!
The attack append-only attack H(m,k) - linked by user49075 on the comments - described in section 6 of the HMAC paper, "Keying hash functions for message authentication" by Bellare, Canetti, and Krawczyk only works if

The hash function is not collision-resistant, and
The collision pairs have the same length.

Of course, once the hash function is turned into non-collision resistant like MD5 and SHA-1, it might be easy to find files that have the same length.
The good point is that HMAC doesn't require the underlying hash function to be collision-resistant.

New Proofs for NMAC and HMAC: Security without Collision-Resistance

So you can use HMAC-SHA1 even though SHA-1 has lost its collision resistance.
The construction of the HMAC is complex due to the Merkle-Damgard construction. With the SHA-3, due to it's resistance to length extension attack, one can use KMAC
Similarly, one can use Blake2(K||m) safely since Blake2's design is based on the HAIFA constitution and that can be easily turned into length extension attack resistant hash function as in Blake2.

Why HAIFA and sponge constructions are not prone to length extension attacks?


I think this will make it pass

https://compromised.server.com?example.com/

As long as example.com/ is at the end of the URL and there are no other slashes, you can add as many query parameters as you want with other data.


Why must I have a "strong" password for sites like this?

Do you remember earlier this year when Apple's cloud was hacked?

Well, Apple's cloud wasn't hacked. Some celebrities with really weak passwords had their passwords guessed.

But the headlines will still read that Apple's cloud got hacked. And that is why you don't allow users to use really weak passwords.


Is it safe to buy smart home products from second hand?

I'll answer the information security part of your question, i.e. whether it is safe to buy smart home products from second hand. Regarding the second part, I admit I have no idea whether Eve Thermo could be reprogrammed properly, but this might be worth asking directly the manufacturer.

Short answer: you're taking more risk buying a used product versus buying new directly from manufacturer. Depending how much money you save, this extra risk might or might not worth the reward.

Long answer: it depends on your definition of safety, but generally this is bad idea if you're concerned about security. Any "smart home" product which had been into skilled hands may be tampered with, and it may be difficult or impossible uncover such tampering. Here is my Youtube video where I show how a regular keypad electronic lock (not even a "smart" one) can be hijacked, so then it could be opened without typing in a code. Note that there are no visible changes on the lock itself.  This is much easier with "smart" devices which you're going to connect to your network anyway.

The risk of course is lower with Eve Thermo type of devices, but still exists.


C:\Windows\System32\drivers\etc\hosts is pretty commonly used to check for read access to the file system while pentesting. If I remember correctly, this file exists on Windows 7 and later, but I'm not sure if it exists on earlier versions.


Suppose you encrypt two messages with the same key, and the two messages begin with the same 16 bytes of plaintext. (16 bytes is the block size for AES, regardless of the key size.) Will the first block of ciphertext be the same? If it is, you're already leaking some information to the attacker. Whether this information is sensitive or not depends on your application, but it's already a bad sign. If the encryption leaks more than the sign of the messages, it's not doing its job.

The basic idea of an IV is to prepend a bit of random content to each message, in a principled way. How this works precisely depends on the mode. (The core AES operation only works on 16-byte blocks. A mode is a way to extend this to longer messages.) For example, with CBC, the encryption of each block is computed from the key, the plaintext block and the ciphertext of the previous block; for the very first block, the IV is used instead of the ciphertext of the non-existent previous block. The IV is normally sent in cleartext alongside the ciphertext, usually it is sent a the first 16 bytes of the encrypted message.

CTR mode technically uses a counter and not an IV, but operationally they work very similarly: a 16-byte random value is generated at random by the sender and sent at the beginning of the encrypted message. With CTR mode, reusing that value for another message is catastrophic, because CTR works by XORing the plaintext with a pseudorandom stream deduced from the key and counter. If you have two encrypted messages that use the same counter value, their XOR is the XOR of the two plaintexts.

There are more attacks against improperly-chosen IVs than I've listed here. Generate a random IV for each message (using a cryptographic-quality random generator, the same you'd use to generate a key), and you'll be fine.

There is one exception: if you generate a fresh key for each message, you can pick a predictable IV (all-bits 0 or whatever). You still need to use a mode with an IV (ECB is not fine, for example it exposes repetitions in the plaintext since two identical input blocks will have the same encryption). That's a rare case though (it arises for storage, not for communication).

Note that encryption a priori only ensures the confidentiality of the data, not its integrity. Depending on what you do with the data, this may be a problem. In particular, if an attacker can submit tentative ciphertexts to be decrypted, or can provide additional plaintexts to be encrypted, this can expose some information. Some modes such as EAX and GCM provide authenticated encryption: a ciphertext will only be decrypted if it's genuine. Use one of these if possible.

Note also that AES-128 is just as secure in practice as AES-256.

If you aren't comfortable with what you're doing, try to use some high-level library rather than grappling with the crypto directly.


How does using an auth server for mobile app and not storing API keys on client add security?

Here's my breakdown of the hackernoon.com articles you link to.

Threat model

They are trying to protect against these attacks:

Sniffing the traffic between your app and the server (possibly because the Android device is compromised)
A hacker gets the binaries for your app and reverse-engineers it to extract any secrets / keys.

Techniques they recommend

Rather than putting your API key in an auth header, use some kind of symmetric or asymmetric cryptography so that the secret itself is not sent over the network.
Obfuscate secret strings that you include in the app binary.
Build a proxy server that handles all 3rd party API requests on behalf of the clients / apps.

Proxy server in more detail

The example they use is this: you have an Android app which loads images from NASA over their API. The NASA API requires you to register for a developer API key which they use for billing or wtv; every request to the NASA API needs that API key included.

They are suggesting that you do not include the NASA API key in your app binary because if you do then anyone who reverse-engineers this key out of your app binary can start making request to NASA that go on your credit card.

Instead, they suggest that you build a "proxy server" where the client / app can say "Hi proxy server, can you fetch this image from NASA for me?". With this approach, the NASA API key that's attached to your credit card is stored on the proxy server, not in the app binary. Of course, an attacker who reverse-engineers your app can still make requests to your proxy server, but now **you* (rather than NASA) have full control over:

1) The authentication mechanism between your client / app and your proxy server, so if you want to do some stronger auth mechanism, you can.

2) Which of NASA's API endpoints the attacker can access through your API key. For example, maybe your API key would let an attacker access the full archives of high-res telescope images or other scientific data, all billed to your credit card. But if your app only needs to picture of the day, then your proxy server adds a point where you can enforce this restriction.

I hope this is helpful.


Is using a public-key for logging in to SSH any better than saving a password?

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.
First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.
After the channel is functional and secure, authentication of the user takes place.
The two usual ways of doing that is by using a password or a public key pair.
The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access.
In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user.  If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model. (In SSHv2 something a bit different but conceptually close is actually used)
As you can imagine, in the first case the password is actually sent to the server (unless SSH would use password challenge response), in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSH traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) or has access to the server or client, your password will be known - with public-private key authentication and the challenge response model your private details will never fall in the hand of the attacker.
So even if one server you connect to is compromised, other servers you use the same key for would not be!
There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise as an unencrypted password file would do, but it's easier to decrypt (on login) and use the private key. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.
Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key – There are ways around that. You can increase the usability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type ssh remote-system-ip and log in, without providing a passphrase, and do that multiple times until you log out of your session.
So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client, the server or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions and servers.


You should look for open source solutions whenever possible since closed source solutions aren't subject to as much inspection.  Apparently the Guardian Project's links passed this test.

If you want anonymous web browsing, then you probably want Tor, which the Guardian Project lists.  Off-the-Record works quite well for encrypted IMs, but it's vulnerable to traffic analysis.

The Guardian Project recommends the full disk encryption program LUKS, which sounds good.  You can however protect specific directories under Linux and BSD (Mac OS X) using EncFS's mount-on-demand mode and an external password prompt program.

encfs -idle=30 --ondemand --extpass='.../ssh-askpass' ~/.private.encfs ~/.private

In theory, you'd see an ssh password prompt if any application attempted to access any file inside that directory, assuming 30 min had elapsed since you'd last accessed it.

This will not work if an application attempts to access the data too frequently because encfs will never reach the idle timeout.  Ergo, you might need to play around with exactly what applications support such operation.


I was facing same issue. Was able to get the connected devices on mobile hotspot but not on a router.
Sometimes netdiscover ARP packets timeout in real networks which is very common, Hence, to increase the number of packets sent for scanning, use the following command:
netdiscover -c 10 -r ip_range -i interface-name

This worked for me.


I gave my cell number to a stranger on the internet. Have I fallen victim to a scam?

Let's go through the process of what actually happened:

Telegram requires a cell phone number to be linked in order to create an account.

To verify that the number exists, they send out a verification code for you to enter in the app while creating the account.

This person obviously didn't want their own cell phone number to be linked to the Telegram account, which is an indication they might use it in malicious ways (terrorism, hacking, …), so:

They tried to set you up to get that code.

So to answer your questions:

Was this a scam?

I'd call it gray zone. But yes, someone did try to scam you for a Telegram verification code.

If yes, did I prevent the scam by denying this user the code?

Yes, you did well, using common sense :-)

If not, what's at risk? Is my bank account at risk, for instance? (I only gave the user my cell phone number. No name, no address, nothing else whatsoever)

That depends, how visible are you on the internet? If you have domain names registered with that number, they can find that. Facebook linked? They can likely find that depending on privacy settings. In brief, if you've linked that number to a lot of accounts, they might find those accounts and the information that's publicly in them.

If I am at risk, what do I need to do to prevent any theft of my information, passwords, money, etc.?

"At risk" is a heavy word in this situation. They just want a Telegram account; I find it likely they just moved on to one of the other 50 people they PMed while talking to you.

Just keep an eye open for "strange things" (like hacking attempts to other accounts etc.), research yourself with that phone number and see if what you can find needs changing.


Bypass frontend ampersand encoding and perform XSS

tl/dr: Most likely there is no exploit here.  The behavior of the backend (passing down unescaped data) is perfectly normal and
  acceptable, as escaping has to happen on the frontend.  Moreover,
  escaping on the frontend most likely is happening, but the behavior
  of the Inspect Element tool in Chrome can confuse that issue.

Overview of examples

Both these issues can be quite complicated so I'm going to show a number of examples to demonstrate what is happening.  To have some useful examples you need both a backend and frontend.  However, I'm not actually going to have a backend so that you can easily reproduce it yourself.  Instead I'm just going to have some static files that act like a backend, and I'm going to use some simple JavaScript to both demonstrate proper frontend security and how Chrome can confuse the issue if you aren't familiar with some key details.  The following examples make actual HTTP requests so you'll have to have these files hosted by an webserver - if you try doing this with local files (aka File -> Open) Chrome will complain about CORS issues that you can't fix.

Safely setting HTML attributes

Anyway we're going to start with an example that is not vulnerable to XSS.  Here's an HTML file with some javascript:

index.html:

Test: Secure

response.json is just a plain text file in the same folder as the above HTML file and contains:

{"name": "\">"}

Therefore when the page loads it makes an HTTP request for some JSON (which includes your payload), parses it, and then sets its contents as the title of our span.  Despite a valid XSS payload no alert will fire.  If you hover over the span you'll see your payload, and if you inspect element you'll see this:

">Secure

Which looks like it should have worked, but it clearly didn't.  That's just because of the way Chrome shows such content though.  If you right click the span in the "Inspect Element" window and click "Edit as HTML" it will change to:

">Secure

Which you can see is perfectly secure.  There was no vulnerability.  Chrome confused the issue because in the "Inspect Element" window it showed the &quot as an actual ".  The reason it is secure is because, in essence, there are many "safe" methods available in JavaScript that leave no room for XSS.  For these methods Chrome itself automatically applies the proper "escaping".  Using these safe methods is the equivalent of using prepared queries with SQL, and as long as this is what the frontend is doing, you have no hopes of an XSS vulnerability (or at least if you did find an XSS vulnerability for one of these safe methods you would have a high-value browser 0-day and could get tens of thousands of dollars from Google for it).

When you don't understand what Chrome is doing though it can be very confusing, because in the inspect element tool it looks like your exploit worked.  It didn't of course, the inspect element tool just shows the escaped characters as their replacements because... well... that's just how it is made.

A note about React, Angular, et al....

Further, note that modern frontend frameworks like React and Angular know which methods are safe and which methods aren't and use the safe methods exclusively.  As a result the risk of XSS vulnerabilities are effectively zero when using modern frontend frameworks "properly".

A note about escaping on the backend

Note that this is also why it's important not to escape on the backend.  Imagine there is no payload, a user used an actual quote in the data, and we escaped it when we sent it down.  As a result we'll change our response to:

{"name": "&quot;Awesome!&quot;"}

When we hover we'll see a title of &quot;Awesome!&quot; and if we inspect element and then Edit as HTML to see what the browser is actually doing we'll see:

Secure

AKA the browser escaped our already escaped data, leading to double escaping and a really weird result for users.  This is not what we want, and would be the equivalent of adding slashes to user input before using prepared queries - it creates more of a mess and is unnecessary.

This is why it's not a problem that the response with your payload looks unescaped - it should be.  Otherwise the application would end up with double escaped data and that would confuse people.

Safely setting tag content

So what would vulnerable code look like?  Let's change our code to show another safe method, except instead of changing the title let's change the actual tag contents, so we'll change our index.html to:

Test: Secure

And our response.json to:

{"name": ""}

When the page loads you'll see:

Test:

With no alert.

Insecurely changing tag contents

Now let's live dangerously.  Change just one line of javascript:

test_element.innerHTML = response.name;

Then reload the page and you will see your alert.  XSS Success!

The difference is that the innerHTML method isn't safe.  It takes the content and renders it as actual HTML, which means that any HTML in the content will actually render/execute as HTML.  In this case you would want to escape your data on the backend before sending it down if it isn't supposed to be HTML.  Of course that would be a dangerous proposition because if your backend forgot to escape the data then you would end up with an XSS vulnerability.  It's much safer to use safe methods exclusively.

Summary

I realize that this is quite a long answer :)  My goal here is to give some understanding about what is happening "under the hood" so you can both understand why Chrome is giving confusing results, and also understand when an application may or may not be vulnerable.  That's quite simple: as long as the application is using "safe" methods to update the DOM then you won't manage an XSS attack anymore than you could execute an SQL payload on a site using prepared queries.  Of course the hard part is determining how the application is handling input and therefore whether or not there is a vulnerability.  Theoretically the JavaScript is available to you so you could always read it and find out, although in practice that is rarely easy...


Is password entry being recorded on camera a realistic concern?

Lots of examples. A high-profile and recent example is when Kanye was caught on camera entering his "00000" password to unlock his device.

Shoulder-surfing is one reason why applications do not display the password text on the screen, but show ****** instead.

And this is one reason why multi-factor authentication is so important; even if you know the password, you cannot use it without another factor.

I have even seen viable research into capturing the sound of the keyboard when a user types the password, even over the computer's microphone.

So, yes, you describe a viable risk that the industry has been addressing for a long time. The specifics of high-res cameras is just not a significant enough of a new factor to consider. Shoulder-surfing and keyloggers are a current risk.

The industry knows that it needs to develop something better than passwords, and there are many active attempts to do so, but nothing is mature or stable enough yet.


Putting user-provided values into an eval() call is a horrible idea, because it essentially amounts to a remote code execution vulnerability. Let's say your code looks like this...

var data = eval(webRequest.Parameters["p"]);

Now imagine I put this into the p parameter...

System.IO.File.Delete(@"c:\windows\system32\ntoskrnl.exe");

Whoops! I just deleted your kernel.

No amount of messing around with escaping will work here - it's a fundamentally broken concept.

Encrypting parameters does nothing but complicate things. Go for the correct approach, and use a session variable like the language is designed to do.

Update: To be clear, I'm talking about eval() in a generic sense. If you're using the Eval binding method on a data controller in C#, you should be OK as long as no user parameters go in there, otherwise they can cause your code to dump out arbitrary values from your database, without even needing SQL injection.


How can I prevent a computer from turning ON?

Out-of-band management
Intel Management Engine and amd DASH are separate microprocessors that remotely manage enterprise PCs. They run with Ring -3 privilege on the machine and run outside of host OS.
It can lock stolen devices, remotely erase data, track location, wake on LAN and wake on wireless LAN, control host OS and detect third party live USB boots.

It is capable of accessing any memory region without the main x86 CPU knowing about the existence of these accesses. It also runs a TCP/IP server on your network interface and packets entering and leaving your machine on certain ports bypass any firewall running on your system. [1]

As it requires a power source, in enterprise Desktops, keeping the switch on is enough for motherboard to draw power as shutting down the host OS does not shut down the AC power supply to the power supply unit of the motherboard.
There is no way to disable it from UEFI. Removing the microprocessor or modifying its firmware which is stored in UEFI will prevent system to boot. Disabling secure boot or using custom UEFI keys will not disable its firmware verification.
This is how Intel verifies it, amd's implementation could be different:

The ME firmware is verified by a secret boot ROM embedded in the chipset that first checks that the SHA256 checksum of the public key matches the one from the factory, and then verifies the RSA signature of the firmware payload by recalculating it and comparing to the stored signature. This means that there is no obvious way to bypass the signature checking, since the checking is done by code stored in a ROM buried in silicon, even though we have the public key and signature. [1]

Once stolen devices are locked, they don't respond to power button signal. In old motherboards with BIOS, they used to respond but immediately shut themselves down.
Consumer PCs also have Intel Management Engine microprocessor and Intel Management Engine Interface driver pre-installed in Windows but Intel Active Management Technology software is not installed by OEMs in consumer PCs.

Can it be reversed, or will this brick the device?

If the device is locked by the remote administrator, it can unlock it using wake on LAN and a specific unlock instruction to the chip. This is how my organisation used to handle enterprise laptops with sensitive data. The chip is bounded with its firmware in UEFI, hardcoded with chipmaker's public key and is probably hardwired to the motherboard in order to brick the device if chip is removed. Intel is secretive about its implementation.
That didn't stop researchers to partially disable it from its firmware:
Disable Intel’s Backdoor On Modern Hardware (2020)
Researchers discovered an undocumented configuration setting that can used to disable the Intel ME master controller that has been likened to a backdoor.  (2017)

Out-of-band management
[1] Intel x86s hide another CPU that can take over your machine (you can't audit it)


Traffic not passing trough OpenVPN Connect on Android

I think the issue lies in your OVPN profile. I see your server IP address is an internal 192.x.x.x address rather than a DDNS or external IP address.

I notice you're also connected to WiFi, which I'm assuming is at home / wherever you set up your VPN server. I imagine if you disconnect it'll give you an error?

It may be a simple matter of just changing the IP address in your OVPN file under remote x.x.x.x 1194 assuming 1194 is the port you've chosen and x.x.x.x is your public IP.

You should ensure that you have port forwarding set up on your router also, and the server will correctly forward your traffic.

This guide is comprehensive, and although its based on Ubuntu 14.04, it translates pretty well to other flavours
OpenVPN Ubuntu 14.04 set up guide


Web application set cookie based on a GET paramater. Is it vulnerable?

It depends, there isn't really enough information to make an informed decision.

The DOS issue in the past was usually described as allowing attackers to overflow cookie space limits for a domain, which can have interesting security ramifications. This is much less of an issue now, though.

There can be larger contextual and system evolution concerns. I saw a case once where an application blindly wrote cookies in this way as a cheap data sharing scheme with related applications on other subdomains. Then the suite was whitelabeled, so the root domain the application was running under was no longer the provider but the client's. Then suddenly other applications under the client domain could have their cookies rewritten. That's fun.

Generally speaking, plenty of applications do just this, and it's fine, but always consider ways to restrict and constrain what gets written (does it have to just be any data, or is there some structure that can be imposed upon it), and always consider the data untrustworthy without validation (e.g. consider adding a signature to ensure what is read is what was written.)


Chrome: why is invalid certificate usage for resources loaded from localhost disabled?

Because insecure by default is bad practice.

As with many things, you have to weigh convenience against security. Your proposal would make many people a little bit less secure, by making the life of very few developers a little bit more convenient. This is really not a great deal to make.

In general, software should aim to be configured by default to be as secure as possible. Any configuration changes that could make the system less secure should be concious choices made by the user or administrator.


LDAP and anonymous bind for PCI compliance

Allowing anonymous bind might permit an unauthorized host to perform authentication attempts if it has access to the LDAP port.  This really only opens a brute-force attack vector, which should be mitigated by the account lockout requirements of PCI DSS 8.5.13 and 8.5.14.  In addition, you can presumably document the network segmentation to show that only relatively trusted networks have the access required to take advantage of LDAP.  You should be able to demonstrate that your PCI DSS 10.2.5 controls are sufficient to detect attempted misuse of the LDAP authentication channel.  You must, of course, use LDAPS (LDAP-over-SSL, 636/tcp) instead of LDAP (unencrypted LDAP, 389/tcp) to be compliant with PCI DSS 8.4.

With those four mitigations in mind, you can probably make a good case for anonymous bind.  Frankly, the alternative is having to store and protect bind credentials on all your endpoints, which in my opinion is more of a problem than anonymous bind.

As with all things, your QSA may disagree, and that's who you have to convince. Documenting controls and reasoning behind your decision should help.


What are the security benefits or risks of HTTP/2?

RFC 7540 Section 10 is a security consideration section that documents a number of security considerations when implementing and/or using HTTP/2. Briefly:

  10.1.  Server Authority
  10.2.  Cross-Protocol Attacks
  10.3.  Intermediary Encapsulation Attacks
  10.4. Cacheability of Pushed Responses
  10.5. Denial-of-Service Considerations
  10.5.1. Limits on Header Block Size
  10.5.2. CONNECT Issues
  10.6. Use of Compression
  10.7. Use of Padding
  10.8. Privacy Considerations

Most of the regular security considerations for HTTP/1 are also still valid, as HTTP/2 has the same application level semantic as HTTP/1.


The editor is great for usability, but it should really be ignored when taking about security against XSS.

It's the sanitizer running on the server that needs to take care of ensuring security of injected HTML. No amount of fiddling in the browser is going to completely protect the user against unsanitized input if you need to mix in HTML (OTOH, if you just want plain text, that's simple, just use innerText).


Is native app vulnerable to FREAK attack? If yes, how to detect it as a user?

Yes, it's the same for native apps.

On Windows, you can simply assume that the application is using SChannel and be right 99% of the time; the same for MacOSX/iOS and Secure Transport.  On Linux, you can run ldd /path/to/program/binary and inspect the output for either libgnutls (GnuTLS) or libssl (OpenSSL/LibreSSL).  I don't know how you'd figure it out for Android.


Are there known security issues with Cuckoo website?

There are generally two kinds of website security alerts:

Blacklist-based, where a threat researcher or server-based scanner determines a page is bad based on thousands of potential criteria, and distributes its findings to clients. Because both humans and machines are making judgement calls, there's plenty of opportunity for legitimate sites to be blacklisted. This is especially prone to happen on security-themed websites since they discuss and include scary-looking things
Client-side script scanning, where the antivirus locally scans and emulates JavaScript in real-time to determine if a website is bad. These results are usually more exact and reliable, but still open to false-positives.

It appears this alert is the first, a blacklist-based detection. It's not surprising a computer security website where you download something to do malware analysis is miscategorized as malware.

Additionally, I've examined the website and run it through URLquery.net and it seems clean to me. I wouldn't worry about this.

Regards,
Swift


Docker was just added his own iptables rules before UFW rules see https://docs.docker.com/articles/networking/ for details.

to avoid the pb I put

DOCKER_OPTS="--ip 127.0.0.1"

in my /etc/default/docker. so I bind only to localhost and it's not reachable from the outside.


Disabling authentication via DSA keys in OpenSSH?

I will first dispute your reasons for deactivating DSA and ECDSA:

There is no known weakness in either which makes them "more vulnerable" than plain RSA.
There has been badly made implementations of DSA or ECDSA; however, there has also been badly made implementations of RSA, and in some case it resulted in RSA key leakage (e.g. Bleichenbacher's attack).
While (EC)DSA requires a fresh source of good randomness, (EC)DSA key generation is vastly easier to perform than RSA key generation. Badly generated RSA keys appear to happen a lot in practice. This article includes an interesting quote about Arjen Lenstra (whom I would personally trust much more on security matters than almost everybody else):

  He said that other formulas such as Diffie-Hellman and DSA aren't as vulnerable because the duplication of a factor makes a key holder vulnerable only to the person who holds the corresponding certificate. "If you have a collision, you only affect one other person. You can hurt them and they can hurt you, but you haven't made it public to everybody and their mother."

If you do not have quality randomness on your server you are doomed anyway.
As for performance, DSA signature verification is no more expensive than the Diffie-Hellman key exchange which takes place anyway at the beginning of each connection. We are talking about one millisecond or so here on a basic PC; I suggest making actual measures before declaring some cryptographic algorithms guilty of slowness. And ECDSA will be typically ten times faster than DSA.

That being said, if you are really intent on deactivating (EC)DSA support on your SSH server, I suggest recompiling OpenSSH (starting with the source for the version packaged in your specific OS) after deactivating DSA and ECDSA in it (look for the key.c, function key_verify(): it suffices to modify it so that (EC)DSA verification always fails, and you will never accept any (EC)DSA-based authentication).

(There does not appear to be an option to selectively deactivate support for asymmetric algorithms. Your server will be deemed to implicitly allow DSA if it has a DSA key, which somehow makes sense. As for client authentication, in the SSH model, this is a decision which is up to each user, who decides to include or not include his RSA/DSA/ECDSA public key in his .ssh/authorized_keys. This might be a case for user education, after all.)


Is showing your IP address in the URL a bad practice?

Easier to hack?   No.  Easier to DoS?  Potentially.   Using an IP address instead of a host name with a DNS entry means you're giving up a layer of routing flexibility that can be very beneficial.

For example, if malware targets your IP address in a DoS attack, if you're using a domain name, you switch the IP address of the site and in the DNS record, and the attack is over without your users knowing the difference.  If your users are making requests directly to your IP, however, that isn't an option.  You're tied to that IP unless you want to inconvenience (and possibly lose) your users along the way.


operating system requiring two or more users to access admin account

What you describe is similar to Shamir's Secret Sharing, in that you need a quorum in order to operate.

However, in you case you are dealing with authorization of admin actions, rather than secret messages. If designing a system around this concept, I wouldn't generally design it that way, but do it as 'tasks' that get queued and need approval from N users.

Suppose Admin1 wants to delete the account of user55. This is an action that requires multiuser approval, so it gets logged and "Deletion of user55" is in pending status. When Admin2 logs into the system later (2 minutes later or next week, it doesn't matter), it sees that the pending of user55 is and approves it since it knows he has left the company. It is at that point that the real action would take place. This would also allow you to set different criteria depending on the sensitivity of the action (like a given action only needs an admin but another requires 5) or the exact role (a junior admin could be allowed to do some things, but certain other would require approval from two seniors).

There are bank accounts that already work this way, where there are several joint owners and the actions need to be approved by all of them. It is quite similar to the way StackExchange works, too.


A shared ID is a very risky approach. If one admins is compromised, then:
A) It may be hard to identify the compromised account and thus hard to analyze why it was compromised.
B) You will have to deactivate or restrict this account, this block admin activities of all admins. Thus administrative tasks will be performed for some time until you resolved the problem.
C) Time to time people change their responsibilities in the company. If some employee doesn't work as an admin anymore, he still has credentials for the shared ID. You would have to (at least) change password every time in such cases.
A better approach is to define a role that gives the needed set of permissions. Then give this role to every admin separately. If needed, you can withdraw admin role without blocking any other permissions and without any side effects for other admins.


What to do with expired certificates as a CA?

The documentation does not talk about it, but a look at the OpenSSL source code, in the apps/ca.c file, seems to indicate that the -updatedb command-line option will trigger a pruning of the index.txt database, converting expired certificates to "expired" status, which replaces the previous "revoked" or "not revoked" status.

(OpenSSL is not the best documented of software packages, especially for the command-line tools. Source code reading is often necessary.)


Encrypt but not verify sender identity https without nagging user?

... set things up so the browser communicates over ssl without giving the user a scary "identity of server not confirmed" warning?

Authentication of the server is done to make sure that the communication is done with the expected server instead of some attacker trying to impersonate the server. It is necessary to protect against active man in the middle attacks where the attacker could decrypt and even modify the traffic.

Authentication of the server is thus essential to provide the protection SSL is promising, encryption without authentication is not sufficient. That's why browsers will complain if the certificate can not be properly verified, for example because the issuer of the certificate is not trusted as in case of self-signed certificates or attacks. It would be very bad if the server could just disable this verification since an attacker could then do this too.

  If I want to buy a https certificate I think the fee is something like $25 per year per domain.

Since several years it is no longer necessary to actually buy a certificate since there are CA which offer these for free - most prominently Let's Encrypt which started two years ago. Several hosting providers even integrate such free certificates already in their offerings for free and with trivial setup or at least provide instructions on how to setup these certificates yourself. If your hosting provider  makes it too hard to use such free certificates you should maybe switch the provider.


I am receiving weird emails regarding GDPR from electronicprivacy.eu

Just got the exact same-very-bad-written-in-French email.
I do have a business (canadian based, but we are mostly working with large companies abroad). It smells very fishy... phishing?

Found this website (in French of course)

https://www.cnil.fr/fr/professionnels-comment-repondre-une-demande-de-droit-dacces

It says :
« Quels justificatifs demander ?
Pour exercer ses droits, la personne doit justifier de son identité. Par principe, cette justification peut intervenir « par tout moyen ». Ainsi, il n’est pas nécessaire de joindre une photocopie d’un titre d’identité en cas d’exercice d’un droit dès lors que l’identité de la personne est suffisamment établie (par exemple, par la présentation d’un numéro client ou des éléments permettant d’identifier des abonnés à un service).
Par ailleurs, dans un environnement numérique, le fait d’exercer ses droits depuis un espace où la personne s’est authentifiée peut être suffisant, en fonction des données d’identité numériques demandées (par exemple FranceConnect).
Néanmoins, si vous avez un « doute raisonnable » sur l’identité du demandeur, vous pouvez lui demander de joindre tout autre document permettant de prouver son identité, comme par exemple, si cela est nécessaire, une photocopie d’une pièce d’identité. En revanche, vous ne pouvez pas exiger systématiquement de telles pièces justificatives, lorsque le contexte ne le justifie pas.
Il est par exemple disproportionné d’exiger automatiquement une copie de la pièce d’identité si le demandeur effectue sa démarche dans un espace où il est déjà authentifié. Une pièce d’identité peut toutefois être demandée en cas de suspicion d’usurpation d’identité ou de piratage du compte par exemple.
Le niveau des vérifications à effectuer peut varier en fonction de la nature de la demande, de la sensibilité des informations communiquées et du contexte dans lequel la demande est faite. »

So basically, ask for a Client Number or anything that could identify the person asking for sensitive data. That should solve the problem; if it's phishong, the person will send you a fake Client Number then you can decline its demand or you'll get no reply to your email. Either way, you'll be safe if ever this email was legit.


Nit: these names come before the blob and thus are prefixes not suffixes.

This standard for the publickey file format is set by OpenSSH, which also also uses it in the known_hosts and authorized_keys files with some more (also prefix!) fields added. See man sshd on Unix with OpenSSH installed or the latest version on the web under "AUTHORIZED_KEYS FILE FORMAT" and "SSH_KNOWN_HOSTS FILE FORMAT". All version 2 keys use a string for keytype and a base64-encoded blob of the publickey as transmitted during SSH(v2) key-exchange, which is defined by several RFCs.

The online manpage no longer includes version 1 keys, although AFAICT all releases to date (through 7.3) still support version 1 BUT strongly discourage its use because it is long obsolete and broken. Version 1 used three decimal numbers: nbits, exponent (small), and modulus (large).

PuTTYgen proactively displays the OpenSSH format, but the SavePublicKey button (or File menu item) writes the different though related format defined by rfc4716 which is also used by OpenSSH ssh-keygen -e/-i. I understand the 'commercial' SSH implementation (fka Tectia) uses this format can't confirm personally.

Keytypes for 'plain' keys are generally defined by the SSHv2 RFCs, linked by an IANA registry. OpenSSH also supports its own form of certificates using keytypes in the vendor-defined format something@openssh.com which aren't registered. Finally, OpenSSH uses the standard-form name ssh-ed25519 even though AFAICT this is still in draft and not yet an RFC.


How is encryption different for Windows yet they are identical?

The green folders are encrypted, the locked folders are locked to the user only(possibly password protected, but not encrypted). A quick google search for folder with lock icons windows 10 shows that they can only be accessed by you, and not anyone else. Green on the other hand means actually encrypted.

A simple test: Send the peglocked folder to someone else(a different user on the same system is fine as well as long as they are the one who downloads it)(through email or some such) and see if they can open it. If so it means it was just user locked, and only the owner on that machine can access it(stupid, but shareable). If they can't and they  get prompted for a password, then it's at least password protected. If you can open it with an OS that will ignore the password and view the contents correctly, then it was just passworded on Windows and not encrypted.

If you weren't prompted to create a key for it, and back it up, it wasn't encrypted. It was just locked or possibly password protected.


TLS is just for connection authentication or as you called it, the "tunnel".  It's really just for mail flow connections between servers and/or clients to make sure that unauthenticated clients/servers aren't permitted to send mail through said host/server.
If they want you to install a certificate on your server, that's for the purpose of verifying that there isn't a rogue or spoofing mail server trying to send them mail using your domain name but not your server.  It's one of many ways to verify the sending server's authenticity to send mail for the respective domain.
Encryption of the email data itself is a completely different technology.  There are various third-party vendors that offer this service, along with open source options such as PGP


Is it safer to store the XSRF value inside your JavaScript?

The only time that you need to worry about the token being read is if there's a malicious extension or an MITM attack being carried out.

In both cases, it's no longer a CSRF problem. Both attacks have the capability of catching the request on the fly (after your javascript has assembled it with the token) and modifying it. This isn't CSRF, but it's still a potent attack. (Using HTTPS solves some of this, though you have to assume that the client isn't installing malicious extensions)

If there's an XSS vulnerability somewhere then it's quite easy to call onsubmit() before submitting.

So there really isn't any added safety.


your calculation seems to be simplified. According to the formula given in RFC 5452, the number of fake packets 'F' that are candidates to be accepted is given by :

P_s  =  D * R * W / ( N * P * I )

where I is the number distinct IDs available (which is 65536 in your case), P is the number of ports used, N is the number of authoritative nameservers for a domain, R is the number of packets sent per second by the attacker, W is the window of opportunity, in seconds and D is the average number of identical outstanding queries of a resolver (typically 1, see Section 5).

If D = 1 (typical value according to the RFC), W = 0.1 (typical value according to the RFC),  N =  2.5 (average value according to the RFC), P = 1 (assume only one port is used) and I = 65536 (provided in your question). Then P_s can be simplified into :

P_s =  R / 1638400

Thus, plugging in the necessary values, for P_s to be 0.99, R should be greater than 1622016 packets/s. Since we used W = 0.1 and you send 1024 false replies per request, then you need about 1622016 * 0.1 / 1024 = 15.84 attempts.

(Hope my calculation is correct)


Ossec is also capable to identify rootkit and backdoor like rkhunter. When I look at the OSSEC default configurations, i've seen following descriptions.

frequency
Frequency that the rootcheck is going to be executed (in seconds).

Defaults: 36000 (10 hours)

Allowed: Time (in seconds)

Also I believe 10 hours is OK for script execution through crontab.


On your non-guest network, Take a computer and setup a shared folder.  Note the computer name and IP address.  Take another device and connect to the guest wifi.  See if you can access the non-guest-computer's share on the guest network.
Is the IP address on your guest machine the same subnet as your non-guest machine.  Can you ping the non-guest machine from the guest-machine?  You did say that "So far I can tell that my devices are on a new subnet." so the ip addresses should be a different IP Scheme.
With the same setup as #1, but on the computer on the guest network, download Wireshark and then start capturing data from your guest wifi.  While the capture is running, go to the non-guest-network computer and do some internet browsing for a minute.  Go back to the Guest computer, and stop the capture.  Remember the IP address from the non-guest computer, and start looking through the capture for that one IP address.  You can setup Filters to do that, such as "ip.addr==[Non.Guest.IP.Address.goes.here]".  Not familiar with that router, but in the Wireshark capture you shouldn't see any stream of "computer" connecting to "google" in your stream.  You might see an ARP request or something of that nature.  When looking through the stream, most things are shown as IP addresses.

Those three things should all give a positive result of:

Can't access the share
Can't ping the non-guest computer, and ip addresses are a different subnet (192.168.1.x for non-guest, and 192.168.55.x for guest as an example)
Can't see any network traffic from the non-guest machine while capturing from the guest machine.

Routers can handle the "guest" network differently than others, and not being familiar with that router, I can only speculate, but these would be the tests I would run if I were testing that out.


On a mobile, does using a password instead of a PIN make encryption stronger?

It depends entirely on the phone. But in general, using a strong password is always better than a weak pin.

The phone may use a key derived from the pin for encryption, in which case pssword is much better and honestly quite necessary.

It may use some secure hw chip to store the key and the chip may limit number of attempts. In this case PIN may be enough.

It can also use something else.


PCI DSS: Is Mirror/ Identical Server in Pentest or Scanning Scope

Yes, the mirror server must be scanned and listed separately in your asset inventory. Identical in technology is never truly identical. All you need is to miss one patch or miss one configuration item on one of the servers.


The "HOST" header is part of the http protocol, vulnerable applications are vulnerable because they insert the value of this header into the application code without proper validation, this means not only applications hosted on Apache/Nginx can be vulnerable. In short, the answer is yes, your application could be vulnerable no matter what kind of language/server you use. Avoid pulling information out of this header, since manipulating it from the client side is trivial.


What is the purpose of derivation of encryption and authorization keys from master key?

Using the same key for two distinct algorithms incurs the risk of interactions. An extreme example is when you use both AES/CBC for encryption and CBC-MAC as MAC algorithm: if you use the same key for both, then it is pretty obvious that the MAC can be trivially worked around. For AES/CBC + HMAC, the gut feeling of most cryptographers is that the two algorithms are sufficiently "different" from each other that these interactions do not occur, but putting a precise, mathematical definition under that term looks challenging.

Basically, this is untrodden territory, so don't do it. Deriving an encryption key and a MAC key from a given master key, using a Key Derivation Function, is the cautious and safe method: it ensures that no deadly interaction may occur. Since you have some HMAC code, use HKDF for such derivation: it is easy to implement, and has received the blessing of many cryptographers.

Alternatively, you may want to ditch both CBC and HMAC, and instead use an authenticated encryption mode which combines encryption and MAC with the same key. These are specialized modes where interactions have been thoroughly analysed, and all nasty details worked out. GCM and EAX are usable without legal hassle, and are fine; GCM is also a NIST standard and is beginning to be widely used (e.g. as part of SSL/TLS).


Is it possible to gain control of a Windows computer with no browser notifications when a user clicks a URL?

Yes, using any browser exploit.
https://en.wikipedia.org/wiki/Browser_exploit
http://krebsonsecurity.com/2010/01/a-peek-inside-the-eleonore-browser-exploit-kit/

What current browser exploits exist is anybody's guess however. No spam filter will be able to filter out all malicious URLs though. You will need to educate your users.


Writing a Password Management System, need advice on database storage

Your solution would work for a very small team. Anyone who knows the keyring password will be able to see all of the secrets stored in the database. If you want to remove a user, you will need to change the password and redistribute it to the rest of the team.

Better approach for collaborative secrets database would be to use asymmetryc encryption. Consider this design:

Every user has its own private and public key registered in the database
Private key is stored enrypted with AES (or other symmetrical algo), with key derived from a user password
Public key is stored unencrypted
Each secret is encrypted with a key generated from a strong CPRNG
The key itself is encrypted with users public key
Sharing a secret is done by encrypting generated key with a public key of the user you want to share the secret with

This is roughly how other password managers (for example LastPass) share secrets.


I think I have the answer. The credentials.json file has the authorization to use the API. For create an application that uses the google api's you need two things: the first one is to request google for permission to use that apis. You might be charged for that use. The second is the usage per se: in that case, the application request a gmail account to upload files.

That's why you have a client-secret: the authorization to consume the API, and secondly, the gmail account in which you are uploading the files.


Is an SSH session to a mistaken site a security exposure?

Yes, the remote server will now have had access to your password. And if they've set it up to log that password (which is not the default in any SSH product I know), you should change your password even quicker than you are already doing :)


Is it suspicious that netstat shows many established connections related with 5KPlayer?

Note that the local address for each connection is on '127.0.0.1', aka localhost.  Because this is a virtual interface, sockets/connections on localhost can only talk to localhost itself.  It looks like 5KPlayer is making a bunch of mDNS queries and leaking the sockets (e.g., not closing the connection when it's finished).  This is almost certainly a bug in 5KPlayer, but not one that indicates an attack or is going to leave you open to security issues.  It's essentially the networking equivalent of a memory leak -- irritating, but not threatening.


Try using VirusTotal website where you can upload your suspicious file(s) and it will scan it for malware (Max file size is 128MB). There are other online scanners as well which may catch it.

You can also try uploading to one of these online sandbox services to analyze suspicious behavior.

If the scans don't show anything, the best way  to preserve the infected machine would be to make an VM image of it using the Disk2vhd tool from Microsoft to preserve its present state so you can get back to a previous known state if you want to reproduce a certain behavior.


Segregating a Printer in my Enterprise Network

You could consider putting the printer on a dedicated subnet in its own VLAN. In lots of enterprise networks there are dedicated 'Device' VLANs.

Because all traffic will then need to traverse a router (and therefore probably a firewall) to get to the subnet the users are on you have the option to put some firewall rules in to make sure:

The printer cannot make any outbound connections
Users can only reach it via the ports and protocols they need (TCP/9100 maybe) rather than the HTTP admin (TCP/80 probably) etc.

You can make exceptions to #2 to allow management access from either the IP address assigned to you on the Users subnet or from another Management subnet which you could create just for your use.


How to deal with low-probability high-impact risks?

Now usually we gauged such problems by multiplying probability of occurrence by the expected damage, but in this case we are lost trying to multiply a number tending to zero by a number tending to infinity and come up with cohesive answer.

Unfortunately this is what you need to do in this case. But I don't believe that this calculation is really as difficult as you make it out to be.

The risk can be estimated by first estimating how many companies face the same security threat and don't take the necessary precautions. Then you skim the news reports to check how many companies get affected by it each year (plus an educated guess how many of them managed to prevent the mess from becoming public). Divide the second number by the first, and you have a risk percentage.

Your damage does not tend towards infinity. The event which would come closest to "infinite damage" would be a collapse of the entire time/space continuum of the universe (and even that's an event where you could make a fermi estimate to quantify the damage in dollars, if you are bored and interested in astrophysics). The highest damage you might be able to cause realistically is bankrupting your company. Maybe you could cause even more damage if you also account for damages caused to other people. But when your company is bankrupt, it can't pay those liabilities. So you can use the net worth of the company as the upper limit of your expected damage.


Has CVE-2014-6271 Shell Shock been mitigated completely what is the latest?

They're the same vulnerability.  CVE-2014-7169 was simply a bug found in the original patch for CVE-2014-6271 or "shell shock".

CVE-2014-7169 allows us to side-step the patch released for BASH that was rolled out alongside the original bug disclosure for CVE-2014-6271.

To test if your system is still vulnerable after applying the patch for CVE-2014-6271, simply type:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo

If you can still pass characters from your environment variables into other environments, your version of BASH is vulnerable.  If so, you should see the date appear on your screen, and a file called "echo" will be created in your /tmp/ directory.

To update BASH type the following, depending on your Linux distro:

yum update bash

or

apt-get update bash


Do we need to have a private key on load balancer

Either you need to install both certificate and private key at the load balancer or none of these.

You need to install both if the load balancer should also to terminate the SSL connection. Such termination is for example done for performance reasons in which case the SSL connection is terminated at the load balancer and forwarded as plain to the final server. Given that you've installed certificate and key at the final server (which would not be needed if it gets only the plain traffic) this is probably not the case in your situation. But it might also be needed for the load balancer to make decision based on the application content, for example to make sure that all traffic with the same cookie always ends up at the same server. In this case the server needs to terminate the SSL traffic too in order to get access to the content and then might talk to the final server either in plain or re-encrypt the traffic using a new SSL connection.

If the load balancer is instead just balancing the traffic based on layer 3/4 information (i.e. source IP+port, destination IP+port) or if it balances based on the server_name extension (SNI) in the ClientHello of the TLS handshake then it does not need to decrypt the traffic which means that it needs neither the certificate nor the private key.


Sign a lot of messages with same private key

It is completely safe to sign any number of messages with an Ed25519 private key. The only non-deterministic input is the hash of the message to be signed and the hash of the private key itself. The number of signatures that would need to be obtained in order to reveal the private key is likely to be so high that an attacker would be better off attempting to crack the key directly.


WPA is the authentication and encryption system preventing people not knowing the right password to access a Wifi network. However, no matter if it is WPA2 protected or not, you may legitimately not trust Wifi networks from hotels and other public places.

The usual advice in such condition is to use a VPN. It is an application which will build a secured tunnel from your PC to the remote VPN server, ensuring that no matter the Wifi security level your connection will remain secure (no other Wifi user will be able to either sniff or alter your communication).

There are a lot of companies offering such service:

Price varying free to a few dozen of dollars,
Service varying from giving you only parameters values to providing you a full fledged automated software allowing you to use the VPN with no technical knowledge (the price pay such service, but also speed: cheapest server may be slower),
Various VPN servers location around the world. For your use, I would recommend a VPN server in the same country as yours since it will limit the speed loss (by making your traffic make a detour to the VPN server it will be obviously slower than direct one, however the nearest the VPN server is, the less significant the difference would be).


Backtrack 5 in a VM - Why bridged networking over NAT?

When in NAT mode the network subsystem of the hypervisor operates by modifying the packets as they leave the host. Assuming TCP/IP over ethernet, the components definitely changed are:

source address
source MAC
usually the TTL
often the source port

Sometimes other TCP flags will get modified as well such as DF, Window size, etc.

In a well behaved network, where all of those flags and options are set in a way that makes sense according to RFC then that stuff can be, and is expected to be, modified appropriately. A vulnerability assessment tool, however, operates by doing things in non-compliant and misbehaved ways. So those normally acceptable header and protocol modifications can actually cause the software to misinterpret the results.

Let's take OS detection as an example. The system will throw a combination of normal and abnormal packets at a system. The network stacks used in most OSes are well known enough that their responses should be predictable in both success and failure situations. So the assessment tool will take the responses, look them up in the OS detection table, and make some guesses about what it thinks the remote host is running based on those responses. Since the NAT device works by munging all of the packets coming in and out you taint your data.

Now, in the vast majority of cases the data may still be totally fine. However, since the packets are modified externally from the assessment tool, the tool won't necessarily know what changes were made. As a result you run the risk of the tool performing analysis on incorrect data which may invalidate your results.

On a related note it has historically been the recommendation to not run host firewalls on vulnerability assessment systems for much the same reason. Since they, by design, spew out abnormal traffic, and since firewalls are designed to protect you from abnormal traffic, it's entirely possible your firewall may drop something in a way unexpected by the assessment tool. Much like the NAT example, this can also invalidate your results.


Its not entirely clear what the actual question is here, but it seems related to CSRF, I will answer the question assuming its related to how best protect against CSRF.

I would recommend implementing the cookie attribute "sameSite" in strict mode [1][2].

SameSite is a 'newer' cookie attribute that's primarily designed to protect against CSRF style attacks. Setting the value to 'STRICT' ensures all of the HTTP methods are protected, i.e., if you set the value to 'LAX', GET requests will send the cookie, while 'POST' requests wont etc. It is suggested that 'LAX' is a balance, but this is somewhat subjective and requires context. Setting to 'STRICT' ensures the browser will never send a cookie other than from the origin.

[1] MDN Cookie Attributes:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

[2] OWASP sameSite
https://www.owasp.org/index.php/SameSite