Why does this PHP object injection exploit work?

The two files

It is important to understand their different roles of the two PHP files that you are using:

one.php is the vulnerable system, the one you are attacking.
two.php The second one is just a tool the attacker can use to generate the serialized object (i.e. data). It isn't supposed to be present on the system that you are attacking, and you don't need it at all. You could just as well generate the data string by hand.

So in a real example the two files wouldn't even be present on the same system. The first would run on the server that is being attacked, and the second would be executed localy at the attackers machine.

So why the same classname in both files? Because when data is deserialized on the server, you want it to create an instance of the utkarsh class. After all, that's the class that will write the file for you. For one.php to create an instance of that object, data needs to contain that object name. And an easy way to create a serialized object string containing that class name is to create a different class with that name and serialize it, just as you have done in two.php.

Note that when one.php runs unserialize it creates an instance of the utkarsh it knows about in one.php and not of the one in two.php.

The actual exploit

The exploit part of your process is making a request for one.php with the serialized object in the data parameter. So why does that result in a successful exploit? Let's go through, step by step, what is actually happening when one.php is executed.

The first row that actually does something is this one:

$v1 = unserialize(@$_GET['data']);

Given the data you provided, it will create an object named $v1 of the class utkarsh (as defined in one.php) with the following properties:

$logfile = "test.php";
$logdata = '<?php system($_GET["cmd"])?>';

Then there's this:

$object =  new utkarsh();
$object->check();

This creates another instance of the utkarsh class. But it's not realy relevant for the exploit in any way as far as I can see - this should work equally well without those two lines.
Then we reach the end of the script. When PHP reaches the end of a script it runs a "shutdown sequence". That includes calling the __destruct method on all objects. So for $v1 it will run this little piece of code:

file_put_contents(__DIR__ . '/'. $this->logfile, $this->logdata)

Or, if we enter the variable values:

file_put_contents(__DIR__ . '/test.php', '<?php system($_GET["cmd"])?>')

There you have it. You are right that "you" didn't write the file - instead you succesfully tricked the PHP script to write the backdoor for you.

Why is the system vulnerable?

The whole reason that this vulnerability is possible is that you pass user data to unserialize. That allows an attacker to create objects in states that they would never be in during "normal" execution of the program, allowing the program to have unexpected effects.


I think, it can be achieved by passing -sigopt rsa_padding_mode:oaep to the openssl req command.


There are multiple approaches an attacker can use for host discovery. I believe netdiscover uses ARP requests for host discovery, which operates on the Ethernet protocol (see https://github.com/alexxy/netdiscover). Other tools like nmap operate at higher protocol layers (ICMP, TCP/IP, UDP/IP, see https://nmap.org/book/man-host-discovery.html). A solution which prevents host discovery at higher protocol layers may not prevent host discovery at lower layers, and vice versa.

A firewall is a common solution for preventing host discovery. For example, Linux can use iptables to prevent host discovery at higher layers and arptables at the lower layers. This doesn't protect against sniffing of traffic by a passive attacker (netdiscover can do this).

Network segmentation or VLANs could further protect against host discovery at the Ethernet layer.

https://en.wikipedia.org/wiki/Private_VLAN
https://en.wikipedia.org/wiki/Network_segmentation


It is not. This is a FUD (fear, uncertainty, and doubt) campaign by GMX because they want to display their ads. There is absolutely no security risk from the mentioned ad blockers. They added some crapware to the list to make it look more legitimate.

Of course such campaigns are very unusual, especially from such a big and well known company like GMX. Unfortunately, I have no English source at hand (because it's a German only campaign) but since you speak German you may want to read this article at heise.de.

Update #1: United Internet, the company behind GMX, received a lot of criticism for misleading customers by falsely claiming that there is a security risk on their PC. The Wall Street Journal (German edition) named the warnings displayed on GMX and the site they link to a "scare campaign".

Update #2: GMX now says that they will no longer display the link when you use ad blockers but will still display it if you use crapware that injects adverts, the list at the site http://www.browsersicherheit.info/ has been updated accordingly and now lists only a small collection of crapware. This list is by no means complete so it is not a reliable source when you want to know if your browser has crapware installed. However, United Internet still maintains it's position that they do not want users who visit their sites to use ad blockers and said they will develop other anti-blocking methods in the future (German source).


What are methods against code leakage for web applications?

Your first solution is the correct one - have an entrypoint file which doesn't contain anything confidential but bootstraps the environment for the app and loads the code from a location unreachable by the web server - in fact that's how pretty much all web frameworks do it - PHP is the only one (to my knowledge) that persists with this stupid idea of putting the code in the web root folder and letting the web server handle URL routing.


Statistics on purposes of viruses/malware

It's unlikely to find open resources that will give you this information in the format you are looking for.

However, you may be able to mine that information out of annual reports published by major Antivirus vendors like Microsoft, Symantec, etc. As an example, Microsoft publishes all its findings in its Security Intelligence Reports every 6 months which is a pretty comprehensive report of all malwares discovered in the wild.


Third-party desktop client for accessing Google Drive cloud storage

Would it be possible for Insync to access my files stored in Google Drive if I make an Insync account and use the desktop application? How?

Since you authorize the desktop application to access your files and since the desktop application is created by Insync they could in theory add a backdoor to the application so that they get access to your files.

  Are there any precautionary measures I should take?

Either you trust them to do the right thing or not. If you don't trust them don't use their apps. There is nothing in between.

Note that is not specific to Insync but the general question of how much you can trust 3rd party software and hardware to handle your data.


Can mprotect() be used to change the permissions of .rodata?

Sections do not exist in the context of a running process, only segments.
mprotect can be used to change the permissions of the pages the text segment is mapped to. Here is a tutorial on how to accomplish this: Writing a Self-Mutating x86_64 C Program
from the notes on the mprotect manual page:

  On Linux it is always permissible to call mprotect() on any address in a process's address space (except for the kernel vsyscall area). In particular it can be used to change existing code mappings to be writable.

Section information is stored in the section header table. The section header table is an array of section headers. The section header table is not mapped to any segment, and not parsed by the program loader. The loader uses segment information only when mapping a program into virtual memory.

Segments - not sections - have permissions, and these are stored in the   segment's program header in the p_flags field. Program headers reside in the binary's program header table.

All of this is documented in chapters 4 and 5 in the System V ABI (generic).

In the output below, we can see the permissions associated with each segment under the flags column:

$ readelf -l /bin/ls

Elf file type is EXEC (Executable file)
Entry point 0x404890
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000019d44 0x0000000000019d44  R E    200000
  LOAD           0x0000000000019df0 0x0000000000619df0 0x0000000000619df0
                 0x0000000000000804 0x0000000000001570  RW     200000
  DYNAMIC        0x0000000000019e08 0x0000000000619e08 0x0000000000619e08
                 0x00000000000001f0 0x00000000000001f0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x000000000001701c 0x000000000041701c 0x000000000041701c
                 0x000000000000072c 0x000000000000072c  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000019df0 0x0000000000619df0 0x0000000000619df0
                 0x0000000000000210 0x0000000000000210  R      1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .jcr .dynamic .got

  The .rodata section in ELF files contains parts of the text segment that are not meant to be changed.

This is false. The entire text segment is Read/Execute.

  By default, all pages from this section are read-only, and any attempt at modification will trigger a general protection fault.

This is false. Segments, not sections,  are mapped to pages (hence the Align values) and have permissions (hence the Flags values).

More info can be found here:

http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/
https://lwn.net/Articles/631631/
http://nairobi-embedded.org/040_elf_sec_seg_vma_mappings.html#section-segment-vma-mappings


Does Non Repudiation offer proof of receipt ?

Non-repudiation binds the sender, not the recipient.  I could, for example, digitally sign a message intended for you.  I wouldn't be able to deny composing the message, but suppose I never sent it?  You'd never get it, even though it was digitally signed.

I can't think of any mechanism not requiring the cooperation of the recipient that proves receipt of a message.  (There's the email return receipt, but a recipient can disable that.)


SSL Handshake Failing With 'Certificate Unknown'

Since you have a bundle that "includes the root certificate," that seems you're using a self-signed certificate, which is (by default and by design, untrusted).

You have a couple of options:

Install the root certificate of your self signed certs into the trusted root store of the workstations that will use this. (Not really recommended because it's clunky, but it will work).
Get an actual certificate from a certificate authority.


Some HSM (I am more used to those from nCipher) allow cloud-like operation: several HSM may share the same "security world", which means that they see the same private keys, which they exchange with each other through encrypted tunnels. Storage itself is not, physically, in the HSM; it is external but encrypted with keys which are kept within the HSM (the complete setup involves several types of smartcards and it is a bit more complex than that, but you get the idea).


Log poisoning prevention in the context of LFI

Notice in the linked article, the technique relies on system() which should be disabled on public-facing PHP processors. Disabling that, and other crazy funcs, should stop a large percentage (ie. shell_exec, passthru, exec, popen, proc_open, ... see https://globedrill.com/disable-dangerous-php-functions-php-hardening-cpanel/) - this control applies to the PHP configuration php.ini option disable_functions. Another relevant option is open_basedir, which is used to restrict file inclusion or operations to directories under this value.
In the context of what reaches the web server, WAFs can be configured to 400 any attempts to inject code into the log via a HTTP request, by blocking the request at the gate.
With respect to what is logged, the web server can ensure user-controlled contents in the log are rendered inert by encoding any data before writing, eg urlencode. This is a sensible thing to establish, at the service layer, as well as the application layer.
At another level, more control can be applied to the directories where log files are placed, and the access that applications have to these dirs. This can be handled by chmod et al. to limit the access, preventing PHP running under the context of the web server to access the log file. Depending on how the server is configured, this probably wouldn't be possible for the web server's logs (at least without some hoop-jumping), but for application logs etc.
Also worth mentioning, .htaccess or equiv can be used to reject any requests for known log files, eg. PHP's error_log.
Finally, within the PHP itself, where the file is brought in with include, require et.al, some filtering could be applied to ensure that the value prepared from user-input is within an acceptable range, possibly by using a regex, eg:
<?php
echo preg_match( '/file1\.php|file2\.php|file3\.php/', $lang_consts_file );


When you install the local tool, anything goes (and it even requires local administrator rights !). The tool can inspect the USB hardware, and just needs a way to "talk" to the Web page. A relatively simple way is to make the tool run a local Web server, and have the page reference that Web server as an iframe. Thus, the user (you) will see the "configuration wizard" as occurring "in the Web page" but it would really be just a display thing, the actual processing being done in the locally installed tool.

There are other ways to make local code interact with a Web page, but a local Web server is one of the simplest and it is easy to make compatible with all the usual Web browsers.


Can the identity of a person in Nigeria be confirmed?

This is probably a scam attempt. You need to sever all communication
Forgive my bluntness. You appear to be an older person. Your age-range is a primary target for Nigerian 419 scammers. Why? You're in prime retirement age, and likely have a 401k plus other savings ripe for the picking.
Please note that nobody will to start a real relationship with a random person out of the blue. Nobody will fall in love with you after a week or two: they are either a scammer, a spy, mentally-ill, a mix, or all of those. They always have ulterior motives. There are really funny ways to screw with these malcontents, but you need to be completely aware of this fact before starting. Something tells me your husband isn't aware.
Keep in mind that "Falling in love with you after a really short duration" is a classic hallmark of a spy, or scammer. Does your husband work for the defense industry? Has he in the past? Has he ever had a security clearance? Have you?
If the answer is "Yes," you need to report it to the government or you will completely lose either clearance. If the answer is "no," he's just being scammed.

Please take note

If they are offering to send you money, they are lying.
If they ask you for money, they are lying.
If they start going "Praise Jesus! He's led me to you so I can give you money," they are lying.
If they quote all the right scripture, they are still lying.
If they need your bank account information for any reason, they are lying.
If they need money for an operation, they are lying.
If they need money for a business investment, they are lying.
If they need your PayPal info, they are lying.
If they need you to do something at Western Union, they are lying.
If they provide Linked-In pages showing the company they work at, don't believe them. (Thanks, Fiasco Labs). In fact, don't visit any of their websites!
If they send you a check to cash, they are lying and you'll be in trouble. (Thanks, halfinformed)
Did I mention they are lying?

Assume the above is true regardless of their nationality. More than likely, you're communicating with someone who claims to be in Nigeria. Maybe he's a prince? Maybe he's offering to split a few hundred million / millions of pounds with you.
Don't believe him/her/it/them, unless you want to lose everything.

Additional Important Information
Rui F Riberio has offered some very important information that I believe should be considered:

If the 100USD was a bank transfer, they already know the bank account, they probably know too many details about the common passwords, parents name, etc...close the account, move the money to another bank.
I would also handle the computer as potentially compromised. One of the photos [fake photos that are really executables; buffer overflows in image parsers] / messages could have helped install a virus that is monitoring the computer. As an cautionary tale someone from my family got defrauded to the tune of 80k, and the bank order transfer came by fax when he was travelling to another continent. Due to the timing, we suspect they got the info from his own emails. Luckily enough the forgery of the signature was not even close to his, and due to Europe laws, he managed to cancel the transfer.
The investigation also found out that at the end of the day, the guy pretending to be him was calling from a voIP account in Indonesia. The guy actually called the bank impersonating him to demand that the transfer was put back in order

Using Psychology against your husband
At this point, your husband is likely too psychologically invested to give up and admit he's been scammed. Admitting that he's been fooled is much harder than coming to terms with the truth. He doesn't want to be seen as a fool, nor does he want to feel ashamed, so he keeps it going in the "hopes" that he'll be right, even if deep-down inside, he knows he's wrong about it.
Some people enjoy hurting others for no good reason, preying on basic human psychology, etc. Those are extreme sociopaths. Only a complete nutter would even desire to do something like this. They really, really don't care about either of you. All they want is your money, and they'll do anything to get it.
This is probably a scam attempt. You need to sever all communication


Are third party authentification provider included via iframe by default considered (in)secure?

I think you see the problem that the user does not know how and where the login form gets submitted without actually inspecting the source code. And that it would be much better if there would be a separate window so that the user can see the URL, ideally together with a trusty looking green bar for https EV certificates.

And although this does not guarantee that the data are actually submitted to this site (i.e. XSS attacks or similar might affect the target or it might be a different target from start) it is better for the user if the same URL is displayed on all logins to the site because this way it can be easier checked if this is the same site as last time and thus if it is still trustworthy.

Therefore I agree with you that this is a usability problem which might make phishing easier and is thus a security problem too. You might point out in your argumentation against X that sites like Paypal never let their login dialogs be embedded into iframes but instead always want to have their own window with the trusty locking green bar and the familiar URL. And they actually teach users to watch out for these signs to detect phishing sites.


Why do mobile devices force user to type password after reboot?

First:

password is used to get access to the full disk encryption key
fingerprint is used to unlock the screen (of an already "decrypted" device)

Encryption key retrieval must be:

accurate - on each entry, the device must transform the password through a key-derivation function into the one and only correct encryption key, otherwise the device won't be able to decrypt the data
secure - derived through a one-way function, not "unlocked" by comparing data provided by a user with a pattern stored on the device

Fingerprint recognition does not meet the above requirements, it is:

fuzzy - on each press the sensor provides the device an approximate image of a part of a fingerprint which is matched at a certain accuracy; on each verification attempt the actual data differs due to different position, skew, press strength
non-secure - recognition is performed by comparing the actual fingerprint with the data stored on the device - this data must be both readable and modifiable which makes it vulnerable to an attacker


Show another number when calling mobile phone

I am not sure how it can be effectively done by directly calling the phone line (such as using phone masking services offered by companies), but I can think of a way of doing that using the data line (wi-fi/3g etc) first and then starting the call.

Attacker creates a program which pretends doing something useful, however it also has an activity/screen which exactly imitates the phone call activity/screen. After installed in the OS, program starts a service which tries to communicate (using 3g or wi-fi) with the server of the attacker when needed. When they want to communicate, phone call imitator activity is started and user is deceived with a number like 911. User thinks he/she is answering the call, however in fact he/she is the one who is calling the attackers phone which is obviously not 911.


Allow copy-paste into MS Remote Desktop, but not copy from there?

Like @paj28 indicated it's not possible to limit the Clipboard functionality one way.

You would need to disable it completely.


X Y Problem Challenge: A better long term solution is to create a mapping of PCs to user and physical location. This is actually a CIS Top 20 Recommendation and gives you a lot of opportunities to build off of as you mature your process. Asset matrices are crucial to a lot of security processes.

That being out of the way - for your specific question:

The real question is 'how sensitive do we consider our usernames?". If they're shared publicly elsewhere, it might be worth the efficiency trade off to use the proposed naming scheme. At the end of the day, we're trying to facilitate business without exposing the organization to undue risk. If you don't consider usernames sensitive, then it doesn't really cost you very much to expose them in device names, and you might gain a lot in response time when you need to remote to a system.

For what it's worth, usernames are typically not treated as sensitive, and you can probably expect a hacker with any type of foothold into your environment to have a pretty good idea of what usernames are out there. Heck, if you ever send emails outside of the company and have any type of employee listing, you're probably leaking dozens of usernames already.

This is a good example of a risk vs reward trade off in security. It's not an obviously bad idea, and there are perks to implementing it, but there are also trade offs to consider. Your best bet is to sit down and write out a little risk analysis and decide if this scheme is worth the downsides.


Use local admin or domain admin to raise privileges on a machine for administrative purposes?

Risk

Two attack vectors to keep in mind here:

If an attacker compromises the Local Admin account and it uses a common password with other systems in the environment -it's a security risk because of credential sharing.
If a user elevates to a Domain Admin account, his credentials are available in plaintext (during his logged on session) and available in a cached form thereafter. Note: The cached credentials may or may not be available, but they are enabled by default in Windows and store 10 of the last logged-in users. So the security risk here is that if DA credentials are compromised the lateral movement involves the entire domain.

Solution

You know the saying about opinions... (insert cliché here), but here is my recommendation to clients.

Randomize the local admin password for all systems in the domain (research Microsoft LAPS for more info), and even systems not in the domain.
Use the local admin for system-level changes (patching, updating, installing, etc)
Set Domain Admin accounts to only be able to logon to Domain Controllers to reduce the risk of leaving credentials in the environment.
Optionally, create a "Power IT User" for admin tasks on servers within the environment that is not a domain admin, if users balk about needing to login as a local admin every time. Be sure to disable cached credentials, and make sure users logoff when finished.


Is it a MUST to create SSH public key fingerprint?

The public key does not contain a fingerprint. The fingerprint is computed by using a hash like MD5 or SHA-1 over the public key. See also Checking ssh public key fingerprints for how to get different fingerprints (using different algorithms) for the same key.


Android & Man In the Middle -- how did Fox News do it?

What is this device? (is it something that the general public can access?)

This one I can't answer. I'm not sure of the actual model/brand, maybe someone else can answer this specific question.

  Is it actually possible what they did? (Isn't the traffic encrypted?)

Yes it is possible to do this even if the traffic is encrypted. Typically you will install the MITM proxy's certificate on the device and then the device will have no idea anything "bad" is happening. For example, you can perform this type of MITM with a Wifi Pineapple and Burp Suite as long as you install the Burp certificate on your device (which is straightforward).

You can also perform this kind of analysis (sniffing TLS-encrypted traffic) using a variety of other proxies, for example, Charles Proxy.

  If it is possible, how would one do this experiment in 2018?

This can be done in 2018 using one of the methods described above.


Why not get rid of all certificate authorities and all the special kind of SSL certificates there are (extended validation etc. etc.) and instead just require anyone who wanted SSL to write their own self signed SSL certificate and then have them stored in DNS records.

There is even a standard for this: DANE. And it is already in use with some sites, but currently mainly for SMTPS and not HTTPS.

But, it needs DNSSec to make sure that DNS lookups are not spoofed. Because otherwise a man-in-the-middle attacker could simply send its own certificate inside the DNS lookup. Unfortunately DNSSec is not widely used at the moment, so for now we have to live with the established PKI structure.

But once DNSSec is deployed deep enough DANE is a promising technology and you can use it to either use your own self-signed certificates or to have an additional trust path with the traditional CA based certificates.


Is it safe to publish public PGP authentication subkeys?

By providing more keys to potential attackers than necessary, you are violating the principle of least privilege (why should anyone else have the privilege to view your public key?). If they don't have to know, there is no point in helping them deduct further information, e.g. the key type (RSA, ECDSA, ...) and size (e.g. 2048 bit) of your SSH key to find attack vectors. From this they could make more informed guesses about how you generally secure your systems, how fast you switch to new technologies and how paranoid you generally are (hmm, still using 1024 bit RSA? Oh, 512 bit ECDSA, interesting...).

Imagine at the moment of key generation you were not aware that a 512 bit RSA key can be cracked on a normal laptop nowadays. Attackers actively searching for such keys online would mark you as an easy target immediately.
Or imagine you forget to ever replace that key and/or forgot about your server (or you're simply not alive anymore to make changes). In X years, the private part of your 2048 bit RSA key can be calculated on a more advanced computation system and the data you have on your server will be at risk. It may not affect you anymore, but maybe you store someone else's data who will still care about keeping it secret.

Of course those scenarios are very unlikely (except for using weak keys, that happens regularly to people; even a 4096 bit RSA key is worthless if the state of the entropy pool was bad, see how lacking the world is at generating good keys in this paper), and probably a bug in SSH will allow exploitation of your server before that key of yours will be cracked, but their probability is not zero, and you should at least consider them before publishing more data than you need to. If you've considered these scenarios, you should be fine, but we all know that nobody can predict all attack scenarios or implications, so it's easier not having to think about them at all.

If you need to upload your SSH auth key to look it up, e.g. for configuring a new server's authorized_keys file, better host it on a URL that is hard to guess, e.g. www.mydomain.com/download/myAwesomePublicSSHkey.pub


Is it possible to run a MITM attack on WIFI hotspot

Sure! If you want, buy yourself a WiFi Pineapple and you can do the attack yourself.


Is it possible a scammer stole my credit card details and made a new card from it?

Credit card fraud is very common and very easy to perpetrate when dealing with magnetic swipe cards.

Credit cards can be duplicated very easily. All it takes is a machine that can read and store the data on the magnetic stripe; writing that data to a blank card can be done later. This process is often called skimming, and it can happen almost anywhere. The necessary hardware is very cheap and easy to find.

Skimmers can tamper with credit card machines at merchants, or they tamper with ATMs. With ATMs, they often capture the PIN entry with a small camera. Unattended machines such as gas stations and standalone ATMs are most frequently targeted, but almost any machine could be affected. It is also possible for service staff such as waiters/waitresses to carry hand-held skimmers.

This is why most banks are switching to chip-enabled cards. While there is no such thing as perfect security, it is significantly more difficult to compromise the chip. The cryptographic secret stored on the chip is never transmitted, so it cannot simply be read by an attacker.


Secure Mobile Payments using HTTPS Web App

Is the HTML5 application loaded in a mobile browser or using WebView Canvas.   Browsers acts as a sandbox, but an HTML 5 App opened using WebView no longer has the same security, but it can be made most secure by following some of the guidelines listed in the link below.

http://www.acsac.org/2011/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=111&type=2&OPENCONF=e319837c671fd746a922ba2662e19fca

Some of the highlights:

All the pages you load in the webview should be from a source you
agree to trust.  So loading a facebook page or a forum page or
similar page is not secure.
Only load trusted page in webview. For
all others open in web browser
Make sure the HTML 5 app has minimal
permissions (don't allow access to camera or contacts in the phone
unless absolutely needed).
Don't load a any page in your app which
has advertisements unless you are willing to trust them, which I
think you should not for an app which accepts payment.  Even if the
ad was served on one of your previous page and not on the payment
page (enter credit cards),  the WebView model in Android and iPhone
allows access across content of multiple pages...(see the link for
detailed explaination).

Bottomline:  The app should only load pages in webview which you absolutely trust.

I check the PCI compliance docs, there is no current explicit guidelines for how to accept PCI data in a Mobile application and they are working on creating a guidelines for it (as of Dec, 2011).  Until then, follow as much of PCI guidelines as possible like never store private data on the phone and others.

I hope the above was helpful.  I have been searching doe PCI compliance guideline for HTML 5 app opened in WebView for the last 3-4 days.

Thanks,


What does it mean that Ikev1 (IPSec) protects peer identities in main mode?

Identity here does not have anything to do with peer IP addresses, which indeed are both visible for anyone along the route. Instead, the identity refers to public keys, as they would identify the peers. From IKEv1 (obsoleted by IKEv2, RFC 7296) Phase 1 Authenticated With Public Key Encryption, RFC 2409, 5.2:

In order to perform the public key encryption, the initiator must
already have the responder's public key. In the case where the
responder has multiple public keys, a hash of the certificate the
initiator is using to encrypt the ancillary information is passed as
part of the third message. In this way the responder can determine
which corresponding private key to use to decrypt the encrypted
payloads and identity protection is retained.
In addition to the nonce, the identities of the parties (IDii and
IDir) are also encrypted with the other party's public key.

The identity protection means that anyone eavesdropping the connection cannot tell anything about the public keys of the peers. Therefore, they only have the IP addresses, but not the identities.


How would one know if they have a rootkit?

A "rootkit" normally tries real hard not to be detected. However, it cannot, in theory, be completely undetectable, since the point of the rootkit is to maintain an entry path for the attacker, so at least the attacker can know whether the root kit is in place or not.

A lot of methods have been used in the past. For instance, some rootkits install themselves in the kernel memory and leave no trace on the hard disk -- thus they are very hard to detect, but will disappear upon next reboot. More commonly, rootkits modify some files or some parts of the disk in order to resist reboots, but they then have to alter the kernel so that their modifications are not visible from processes on the machine.

So, basically, if the rootkit does its job properly, then you will not be able to detect it from the machine itself. You might find out about it if you reboot your machine on a live CD or USB key, and from that OS (presumed clean), inspect the hard disk. If the same files do not look identical, when inspected from the outside (the OS booted on a live CD) and from the inside, then this is a rather definite sign of foul play.

All of this assumes that the rootkit is good at what it is meant to do. There are a number of inexpert rootkits (or inexpert attackers) who will leave traces. For instance, weird files in the home directory of root (or Administrator).

A rootkit makes sense in situations where the attacker gained total control of your machine; the job of the rootkit is to maintain this level of control. The attacker can then see everything you do on the machine, and as long as the rootkit is active, he will be able to keep on seeing everything you do on the machine.

(The term "rootkit" has also been applied to escalation tools, i.e. tools which exploit local vulnerabilities to transform a user-level access into a full adin-level access on the machine. Same result: the machine no longer is your machine.)


Application security architecture framework

If you're looking for more specific application security architecture guidance, I'd be inclined to look at OWASP materials as they're more focused in this area.

Project like the OWASP Developer Guide, OWASP Application Security Verification Standard or OWASP Software Assurance Maturity Model could be of use in this context


Security implications of storing encrypted snapshots on cloud

does the practice of storing snapshots of encrypted sqldiffs undermine hidden-ness of the underlying plain text in any way?

Not quite clear what you are asking here. I assume that you are asking whether it is safe to store encrypted plaintext in the cloud?

The short answer is "maybe".

In theory, this may well be sufficiently safe for the risks it presents. Of course, only people familiar with those risks can realistically make a proper assessment so this answer should, in no way, be taken as a recommendation.

There are a number of potential issues that need to be considered when assessing the risk:

How protective is the encryption being used? Does it meet the latest standards?
How long a key is being used?
Is the passcode strong enough?
Is there only a single passcode? (reusing the same passcodes to encrypt different data can ultimately compromise the encryption).
How is the passcode/key managed? How is it shared? Who has access?
How long does the encrypted data stay online?
How valuable is the data? (is it worth attackers spending lots of time/money to get to the data)

I could go on but hopefully you can see the shape here.

Really, the question is not about putting encrypted data into the cloud, it is, as so often with security, about how things are managed and what is the overall risk and risk appetite.


Should a system require a password confirmation for accounts managed by an administrator?

Frame challenge
I would like to start with a frame challenge, as this is how I design my systems: an administrator should not be able to change other user's passwords.  Of course the standard caveat applies: we all have different needs, and depending on what your system is storing, convenience may trump security and letting an admin change user's passwords might be the best choice for your business.  However, I would say that if there is anything of value in the system then an administrator should not be able to change a user's password.
Instead, your system should have simple self-service password reset capabilities using modern best practices.  In the event that someone is completely locked out of an account you can always create a separate "Account recovery" process that requires separate verification of identity and takes at least a few business
days to get through (a slow account recovery gives the actual account owner time to respond if the attempted account recovery is not actually legitimate).  Again, YMMV, and the techniques you employ will obviously depend upon the value of what your system is protecting.
The main reason for this is because allowing admins to change passwords can effectively destroy audit trails.  "Administrator" doesn't (and shouldn't) mean "Has full access to absolutely everything", and allowing them to change a user's password potentially gives them the ability to evade any built-in auditing you have by taking over another user's account directly.
Finally, giving an admin the ability to change user passwords makes them a target for social engineering attacks if an attacker wants to gain access to someone else's account.  Allowing admins to make changes to accounts is basically what landed AT&T in a $240 million lawsuit over crypto currency theft: https://www.theregister.co.uk/2018/08/15/att_sued_cryptocurrency/
Answering your question
Still, the best answer is not the only answer, so I wanted to answer your actual question.  If you are going to give admin's the ability to change a user's password, whether or not you also ask them to provide their password to change the user's password depends on what you are trying to protect against.
The whole point of asking for a user's password when they change passwords is to protect against further privilege escalation if someone gets access to the user's session.  Whether it is by stolen cookies or simply waiting until someone walks away from their computer with it unlocked, an attacker who gains authenticated access to someone's account could go and change their password to make their access permanent.  Asking for the user's password before allowing a password change makes that much harder.  The attacker is still in the system, but they can't lock out the original user and can't make their access permanent.
The same rule applies here, and therefore your choice depends on how secure you want this to be.  If your admin works in the office, gets up for lunch, and leaves his computer unlocked and still logged in, then anyone could sit down and start changing user passwords.  It's even better if they can go change another admin's password - then they have permanent admin access.  Of course they could also just create another account and make themselves admin, giving themselves permanent access.
One way to prevent those kinds of attacks would be by asking the admin for their password before allowing sensitive changes (changing their password, changing another user's password, creating more admins, etc...).  Ultimately though it is up to you to decide how to balance convenience vs security for your organization.


There is no absolute notion of "lightweightness": by definition, this is a relative notion: on a given architecture, a specific algorithm may be "lighter" than another. Depending on the usage context, this may be "light enough" or not. Moreover, there are several metrics:

On software platforms, we consider CPU usage and RAM usage (both L1 cache for code, depending on code size, and L1 cache for data, exercised by lookup tables).
On hardware platforms (FPGA, ASIC...), silicon area, latency, bandwidth, enery consumption... are important values and neither is "more important" generically than any other.

An algorithm can be lighter than another for one of these metrics, and heavier for another. For instance, with typical implementations, on software platforms, AES will use less CPU than 3DES, but will need from RAM (about 4 kB for constant lookup tables; usually, this cache usage is perfectly tolerable, which is why AES is almost invariably "much faster" than 3DES).

Every researcher eager on touting the performance characteristics of his pet cipher will define his own formal line of weight, his creation being, of course, in the "light" side.


Why unsupervised anomaly-based intrustion detection training data should be normal or less noisy

This is a puzzling question.  The explanation is provided right there in the paper, in some cases right near the quotations you provided.  Perhaps it is worth re-reading the papers through a second time, as it sounds like you might have missed a few details on the first pass.
On the first quotation ("traditional anomaly detection algorithms require..."):

Well, that's just how traditional anomaly detection algorithms work.  Those algorithms work by starting with a training set of normal traffic, and then they use the training set to build a model of what normal traffic looks like.  For this to work right, you need a large collection of normal traffic.  As the paper states in the very next sentence, "if the data contains some intrusions buried within the training data, the algorithm may not detect future instances of these attacks because it will assume that they are normal".  If you want more details on how those sort of algorithms work, then your best bet might be to read some papers that provide examples of algorithms of this form.

On the second quotation (assumptions in unsupervised techniques):

I think it's obvious why we need to assume that attack traffic looks different from normal traffic.  If they looked the same, we'd have no way to detect attack traffic.

As far as why the unsupervised technique of Nieves needs legitimate traffic to be a lot more common than attack traffic: this is explained in Section 4.4 of the paper.  It's because the paper assumes that small clusters represent attack traffic.  Without this assumption, it's not clear how we could tell which of the traffic in our training set was normal and which was attack traffic, without labels.  Remember, the paper assumes we have a training set with a lot of traffic, containing a mixture of both normal and attack traffic, and we don't have any labels to tell of us which of the data in the training set is normal and which is malicious.
As the paper explains, "Based on our assumption that a real network contains many more normal connections than attacks, [we consider] the smaller clusters to contain attacks and the bigger clusters [...] to contain normal or good connections" (slight adjustments to grammar to make it clearer).  In other words, that's just how Nieves' proposal works.  Of course there's nothing that says this is the only possible way to do intrusion detection -- but it gives some explanation why Nieves chose to try out the particular scheme he did.

My earlier answer:
It's hard to know without context (you should've provided a link or citation to the specific paper you're referring to).  Without that, we can only guess.
They might be referring to the difference between supervised learning and unsupervised learning.  In supervised learning, we assume that we have a large training set containing many packets, and every packet is labeled as either 'malicious' or 'legit'.
In unsupervised learning, we assume we have a large data set containing many packets, but none of them are labeled.  If you don't have labels for the training data, about all you can do is cluster the data into one or more clusters.
Finally, there's one more situation that is common for anomaly-based IDS's: we are given a large training set containing many packets, and it is assumed that everything in this training set is legit (non-malicious) and representative of normal non-malicious traffic.  Then, one can try to build a model of what normal traffic looks like; during operation, if you see any packet that deviates from the model, then it might be an attack.  This is the basic concept of anomaly detection.  There are many ways to build a model of normal traffic, but one possibility is to use clustering (e.g., K-means) to cluster the normal traffic into one or more clusters; during operation, any packet in or near one of those clusters is assumed to be normal, non-malicious traffic.  If this is what's going on, you can see that this works even if there is only one cluster.
If I had to make a guess, my guess would be on the latter explanation.  But without a paper citation, it's hard to say for certain.
P.S.  No matter what technique is used, you can hopefully see why it is important that anomalies (i.e., malicious traffic) differs from normal traffic.  If malicious traffic looked the same as normal traffic, you'd have no hope of detecting it.  And, indeed, the entire definition of an anomaly is "something that's different from normal", so for anomaly detection to be useful at detecting attacks, we have to assume that malicious traffic is anomalous (different from normal traffic).


How secure is Asus router's brute-force protection?

It is not secure at all, as it looks like it's enforced on the client because opening a new tab clears the cooldown delay and you can log in straight away again.

A bruteforce script would directly submit username/password pairs to the router without interpreting the page's Javascript code that enforces the block.

This will only slow down manual attackers who don't want to automate the task, but automated attacks will be unaffected. It is scary to see that someone thought such "protection" was a good idea.


Best practice: Should I revoke an identity self-signed using SHA1?

First of all, this will not require you to revoke the user ID/identity, you can simply add a newer self-signature superseding the old, SHA-1 based signature.

I wouldn't care about the old signature. On one hand, self-signatures can be reissued as you want to, in fact they're reissued whenever you change the key preferences (those are stored in self-signatures), while the newest is to be considered the "valid" one.

Don't care about cluttering the key server network. Adding a revocation is just one more signature (or rather, one per user ID), this is no notable change for the key servers (there are thousands of new certifications each day).

But would it make sense? Well, a revocation usually explains something's fishy about the revoked signature. It was issued by mistake, you realized after some time that it was issued on wrong assumptions, the certification was not issued by you (although you'd probably rather revoke the whole key in this case).

SHA-1 might not prove secure enough in the near future. What does this mean for self signatures? You should not trust SHA-1 signatures at all any more in this case, as each of them could have been issued by an attacker. If you revoke your old SHA-1 signature, this will still not prevent an attacker from issuing new faked certifications. You generally only should consider trustworthy signatures, and ignore all others. I wouldn't treat untrustworthy self-signatures differently from ones issued by untrusted keys or weak algorithms, and simply ignore them.

All in all: the important part is you do have a trustworthy, new self-signature. The old one does not really matter any more, revoke it if you want, keep it if you don't want to clutter your key listing -- or are too lazy.


How to secure a websocket connection with challenge-response?

This leads to question #1: the Javascript code sent to the browser must contain the shared secret. So the shared secret is not very secret, is it? So how can we consider this a secure method of authentication?

If you study the documentation of the Challenge Response Authentication with WAMP you should notice the following information:

  The client and the server share a secret. The secret never travels the wire,

Instead it is considered that the secret was shared before doing the authentication:

  The actual pre-sharing of the secret is outside the scope of the authentication mechanism.

In case of using Websockets from the browser that probably means that the code which contains the secret should be transferred with TLS. When using Websockets inside a standalone application shipped to the user the secret can be pre-shipped inside the application. Since the secret itself is not specific to the user but only used to secure the communication it can be exchanged before any kind of authentication.

  Important note: all connections will be secured via TLS.

WAMP-CRA is explicitly designed to be usable with non-TLS. From the documentation:

  ... hence WAMP-CRA can be used via non-TLS connections

Of course WAMP-CRA can be used with TLS, but if you have a secure connection already you don't need to use a protocol designed to work within the limitations of non-TLS, but you could use a much simpler authentication like cookie-based or make use of mutual authentication provided by TLS.

  ... Which brings me to question #2 ... And finally, question #3:

Since your original assumption was wrong there is no need to add security on top of the existing protocol. Thus I don't cover these parts of the question which deal with the security of your added authentication layer.

But a more general answer, independent from the framework you use: Websockets are a communication channel created by upgrading an existing HTTP(s) connection. This means any kind of authentication done for the HTTP(s) connection can be applied to the Websocket connection, i.e. mutual TLS authentication, Basic Authentication, session cookies etc. Thus if the HTTP(s) connection is already authenticated their is no need to do an additional authentication inside the Websockets channel because this is the same TCP/TLS connection which was already authorized.


Does any PXE/Full disk encryption password concept like this exist?

There´s a project called iPXE that gives you an open source network boot firmware. It can flashed on the network card or chainloaded after the default firmware is started.

You could improve it to add this functionality you describe (if I understood correctly):

the remote server has everything encrypted, so need a password to start.
Your customized iPXE will boot, and ask for a image from a HTTP server, by some secure communication method. Those traditional secure handshake protocols could be used.
the server would validated the request and then send the boot image
this boot image would decrypt the HDD and continue the boot operation

Can be done. And I think people at iPXE could enjoy it.


Can keylogger software exist solely on a keyboard PCB?

The answer that you don't really want is that keyloggers can be very stealthily incorporated into pretty much anything:

Keyboard with integrated keylogger:
https://www.paraben-sticks.com/keyboard-keylogger.html
Less savoury keylogger found in retail keyboard, sending keystrokes back:
https://thehackernews.com/2017/11/mantistek-keyboard-keylogger.html
Wifi keylogger in a USB extension cord:
https://www.amazon.co.uk/AirDrive-Forensic-Keylogger-Cable-Pro/dp/B07DCCBBHT
QMK the firmware used on many handmade keyboards is fully programmable. Many keyboards use quite sophisticated CPUs (QMK supports e.g. Atmel AVR and ARM processors) . Adding an sdcard to a mainboard is quite easy.

All of this is fairly irrelevant, because you're approaching the issue from the wrong direction:

  since I am not planning on wiring a keylogger into my own keyboard I
  feel as though I should be safe

This is assuming that the threat model that IT Security are working with are you being an unassuming victim to something like the second link. The more probable route is assuming that you are a potentially malicious insider, and aiming to use a stealthed keylogger, coupled with standard business practices ("Hey, {Admin}, I need this totally legitimate software, can you just enter your credentials to install it?").

While the first option is something to protect from, the second may also be considered. Luckily for the IT Security team, the solution is simple, known and approved keyboards are the only ones to be used.

Unfortunately, this isn't good for your prospects on this.


Could an Smart TV be a threat for a hotel?

SmartTV's have about the same security of other IoT devices like network-capable DVD players, IP cameras, routers, printers etc. This means: while there are some vendors which actually care about security there are others which don't. Specifically with the cheaper devices the chance is higher that the device is insecure but spending lots of money does not guarantee security either.

And if such device gets compromised it can both be a danger for the local network as for the rest of the internet. For one security issues might allow the device to be taken over from outside so that it can be used as part of a botnet to attack other systems, to spread spam and malware etc. But one notably difference between a SmartTV in a hotel and others IoT devices there like IP cameras, routers or printers is that the customer is actually expected to interact with the device and that the customer has physical access to it. If the device is in the same network as sensitive systems it might be used to attack other devices in this network. Putting these potential insecure devices into a different and strictly separated network will mitigate this risk.

It does not matter much what kind of OS is installed on the device. More important is if the software is recent (and not some old Android with known security issues) and if the vendor actually cares about security and provides quickly updates when needed.

For more information about this topic see for example How my TV got infected with ransomware and what you can learn from it or Samsung and Roku Smart TVs Vulnerable to Hacking, Consumer Reports Finds.


Does red-teaming encompass the entire skillset of a blue-teamer?

The idea that redteamers or pentesters are 'skilled up' from blueteamers is a misconception, plain and simple.

In the same way that you can defend against XSS without necessarily knowing how to construct a complex XSS attack (which encompasses more than just the XSS code itself, i.e. the payload), you don't need to know how to write code to prevent XSS before you can construct one.

There are a TON of people who work as redteamers or pentesters without ever having worked in a SOC, or on a blueteam, or certainly done any professional software dev (and thus, no secure coding experience).

Don't let anyone tell you otherwise.

Now, whether blueteamers and readteamers should know how to do both jobs is an entirely separate debate.


This isn't about encryption, this is about finding an application that does what you want. Encryption is just a tool to secure information, and so is PKI, but it's only one way to go about it. In fact, encryption is not really ideal for what you are trying to do, as you are in essence using encryption in place of account management.  What you need is an application where you say which data is for which groups and it goes and does it for you. As for encryption it's unlikely you'd need encryption of data at rest, so just use SSL.

Unless you really are paranoid about data security  I suggest you use web-based collaboration tools like evernote or the like, that way someone else handles the dirty work and you just handle the content.


Transparent Proxy with tight whitelist, permitting GET requests still prevents data egress?

I don't think your average virus is designed to circumvent whitelist blocks, and doing so via a forum question seems too low bandwidth to be worrisome (or interesting for the average virus writer).

I say 'average', because this kind of behaviour is more to be expected of a tailored virus designed to exfiltrate very selected information from your network.

But, at that point (i.e. a virus designed just for your systems), I wonder whether it wouldn't be possible to setup some sort of covert channel - haven0t tested it, but maybe reading a question via GET increments its view counter? In that case the virus and its CCC server could agree beforehand on a number of very old questions, that are unlikely to get views, and the combination in which to view them in order to encode a given sequence of bits.

I think that for the "average" scenario you're doing way too much (but, hey, better safe than sorry - belt and suspenders and all that). For the "they're looking for you" scenario, isolated (and expendable, maybe just through imaging and reformatting) workstations and physical compartmentalization of Stack Overflow queries and sensitive information seem preferable.


Determine encoding/hashing methods used based on knowing the input and output only?

Is there any way to determine that based on the above data alone aside from just trying a bunch of common hashing/encoding sequences on the original strings and hoping to stumble across a matching output?

No, there is no other way. Sometimes we get hints from knowing the length of things (MD5 hashes are shorter than SHA-256, etc.), but that still doesn't promise you anything.


MITM Traffic forwarding not working on Kali

Figured it out! When I brought eth0 down like this:

ifconfig eth0 down

traffic forwarding started working.

I think what was happening was the traffic was being forwarded from wlan0 (the external wireless card) to eth0.


How secure is Microsoft's Windows 7 SChannel implementation of TLS 1.2 out of the box?

... it seems if you implement TLS v1.2 in the correct manner you can avoid these issues ...

Some of the CVE you've listed is that TLS 1.2 wasn't implemented in the correct manner, contradicting your assumption. For example Winshock is an implementation problem which remote code execution on the TLS server side. Others are problems in the standard itself, i.e. the triple handshake attacks works even if the standard is correctly implemented.

Which means that an unpatched Windows 7 is vulnerable to these attacks, no matter if TLS 1.2 was correctly implemented on the system (which it wasn't) or not.


Injecting meterpreter/reverse_tcp into apache2 with msfvenom results in seg fault of apache2

Seems like the reference to segmentation refers to the 2 parts of the payload. Try staged and stageless variables, also cmd instead of meterpreter. I believe staged is one string and stageless is segmented. But im not sure i just started playing with msfvenom myzelf


What are some of the worst DBMS for finical software, and why?

Interesting question.  I don't have any specific knowledge of any new DBMS systems that have caused a vulnerability when using a traditional RDBMS would have not led to the same outcome.  As far as integrity goes, I think you make that compromise when you add in "eventually consistent" as a platform goal for a lot of the highly distributed NOSQL offerings.

I don't think it's going on a limb to say that the ecosystem isn't nearly as developed as RDBMS solutions.  That said a lot of the logic that can be found in a RDBMS has moved to the application and is dependent on the developer, which is likely a potential weakness.

Given the reason for implementation is largely scaling related (for Enterprise), would attacks against this platform more likely be attacks against it's distributed nature at least initially.  As an example the Citigroup e-payment flaw, though they probably are using traditional RDBMS.


These days, most wifi routers incorporate various forms of protections against attacks like pixie dust, e.g., not allowing multiple tries for the PIN in quick succession. Some even require a human admin reset after, say, 3 wrong PINs.

Furthermore, the weaknesses of WPS are well known, so more people are disabling it if they can.

Thus, the success rates are not high these days.


Decrypting multi-user secrets in multi-tenant web application

The only problem is: by reading the session files, sysadmins are still able to decrypt messages of logged in users. Is there any protocol to solve this?

You are asking for the impossible - for a system that would provide users with decryption and encryption services while not maintaining any knowledge about how it does it, at any time (otherwise sysadmins will be able to decrypt messages, too!).

You have to decide who you trust and to what degree, because you need to trust someone - in the end it's hardware that runs your code, not you yourself.


Why doesn't Microsoft implement salt on users passwords in Windows?

The handling of passwords in a Microsoft OS is complex because they use passwords for many usages. The OS (or its domain controller) will store a hashed version of the password, but there are also values which are symmetrically encrypted with keys derived from the password or from the hash thereof. The authentication protocols do not include provisions for exchanging salts when some hashing must occur client side. It is difficult to alter the password processing algorithms without impacting a lot of subsystems and potentially breaking the backward compatibility, which is the driving force of the Windows ecosystem.

It goes down to strategic priorities. Microsoft knows that altering password hashing and authentication protocols to include a salt will have some non-negligible costs which they would have to assume (by fixing all the components which are thus affected). On the other hand, not changing the password hashing is rather "free" for them, because a flaky hashing algorithm will not convince customers to switch to other non-Microsoft systems (the OS market is, in practice, a captive market); it takes a lot more to force potential customers to envision an OS switch which is very expensive. Also, password hashing can arguably be qualified as "defence in depth", a second layer which has any impact only once a breach already occurred; as such, it could be presented as being of secondary importance. Therefore, it is logical, if irritating, that Microsoft does not update its poor password processing practices.

Historically, Microsoft did only one update, when they switched from NTLM v1 to v2, and it was kind of necessary because the older LM hash was so weak that it was beginning to be embarrassing. My guess is that it involved a lot of internal hassle and they are not eager to do it again.


New processes are created with system calls, namely fork(), vfork() and clone(). These days, the C functions corresponding to these calls are implemented with an underlying call to clone() (the actual system call, as seen from the kernel), but the two other system calls are still there and could be invoked by any process with a simple bit of assembly.

To trace all user processes, you just have to use ptrace(), and intercept these calls, so that you can attach to new processes immediately after their creation. That's how strace works.


Can anti-virus/virus protection be used to spy on you?

Any software you install on your system can compromise the system and thus affect security and privacy. This can be done either willingly or because of bugs in the software. And this is doubly true for software which runs with elevated privileges, like Antivirus usually do.

And while Antivirus might like to protect you they often have critical bugs which might make your system actually less secure. For more information read High-severity bugs in 25 Symantec/Norton products imperils millions from 2016, Critical flaw in ESET products shows why spy groups are interested in antivirus programs from 2015, Google bod exposes Sophos Antivirus' gaping holes from 2012 or Google researcher blasts Trend Micro for massive Antivirus security hole from 2016, just to name a few.

Apart from that many Antivirus inspect HTTPS connections since encrypted connections are also used to transfer malware. And sometimes they implement this inspection in a wrong way and thus make man in the middle attacks possible which were not possible before. Read The Security Impact of HTTPS Interception for more details.


What is 'Modular shell disassociation from kernel'

I agree with your observations that this specific term is not well-explained and that a lot of sites seem to just parrot each other.

While i am by no means a linux dev, my best guess would be to look at the the unshare() syscall:

  unshare allows ... an ability to
  disassociate parts of the context [such as
  virtual memory and open files]

Source

  unshare can be used to implement polyinstantiated directories using
  the kernel's per-process namespace mechanism. Polyinstantiated directories,
  such as per-user and/or per-security context instance of /tmp, /var/tmp or
  per-security context instance of a user's home directory, isolate user
  processes when working with these directories. Using unshare, a PAM
  module can easily setup a private namespace for a user at login.


Javascript injection via document.cookie possible?

As you point out, if an attacker has rooted the site, you've already lost.  There's a number of things they can do that are far more dangerous to your users than cookie-based XSS.

However, it's possible to set cookies for a domain without rooting the site.  (Such as injecting them if a user is visiting an HTTP page on the same domain, even if that page doesn't contain anything significant or sensitive.)  So let's look at what a cookie can do.

If you output the value of a cookie without escaping it, then there's a definite opportunity for XSS.  If you build a tag (such as a link) with the value of the cookie, you might have an XSS.  Basically, you should be treating cookies as untrusted input anyway, so you shouldn't have an XSS, but it does happen.

Here are a couple of real-world examples:

http://blog.k3170makan.com/2013/10/aboutme-cookie-based-xss.html
http://miladbr.blogspot.com/2013/04/exploiting-unexploitable-dom-based-xss.html
http://research.zscaler.com/2009/05/cookie-based-persistent-xss.html (older link, some resources are broken, still informative though)


Single button click mobile direct carrier billing fraud

It's called HTTP header enrichment. The MSISDN (mobile phone number) is injected in the header once the user hits a whitelisted URL by the operator. Not visible through http://headers.cloxy.net.

The surprise payment was made through something called clickjacking (google it for more info).

Basically your friend needs to complain to operator's customer support and the operator will do a chargeback (refund), Your friend might still be able to access the "Droidboost" service for a short while.

For some reason I guess that you're from Germany, so Vodafone, T-mobile, E+, O2 (whatever operator/carrier) will also probably ban the customer having access to their payment APIs. Hopefully they'll also impose a ban on where some the companies using their payment APIs are "buying traffic", ieg Google adwords.

@André Borie Jan 1 at 13:20
 -  The problem isn't the actual billing method, the problem is obviously which companies and services the operator grants access to their payment APIs. Previously the billing method was used by junk companies in the porn, ringtone and wallpaper genre. Now Google, Microsoft, Apple, Amazon, Spotify, Sony, LG, Samsung and more are rolling out global coverage in carrier/operator payment channels.


Is it safe to skip CSRF checks for non-browsers?

CSRF is for forms mostly and it is not used for REST APIs at all. When REST API is implemented with API keys and nonce, you could say that these 2 act as your cross-site request forgery protection.

Also, when designing REST API it's usually best to avoid such things as cookies at all. Use per-user API Keys, this will also solve your identification problems.

Is it possible to differentiate between machine-to-machine (M2M) and human-to-machine (H2M) clients? If so, what is the best way (is the above approach reasonable)?

For a rest API it should NOT matter if the client is a machine or a human. To identify humans, use per-human API key which should be supplied upon every request. There is no such thing as machine or human (i.e. there is no difference). Everyone is a client for the API.

Is it safe to differentiate between M2M and H2M clients, even if we can? Or does this open us up to possible attacks in the future?

Answered above (you should not need to do this).

Can an attacker delete cookies, assuming that I control all sub-domains and use HTTPS?

Answered above (you should not use cookies for REST APIs).


How do you prevent sending cookie data over HTTP the first time?

In summary of the comments (and by replacing my previous answer): as long as sslstrip is possible the attacker can impersonate the user and control the session while the browser thinks that the user controls the session. Only HSTS can prevent sslstrip and only HSTS preload can prevent sslstrip on the first request (before getting a HSTS header).

Thus HSTS preload should be the way to go as pointed out correctly in the answer by Benoit Esnard.

The problem is, HSTS preload can take months to be available for a  new domain since an updated list ships only with a new version of the browser (at least in case of Google Chrome).

In other words: there is no solution which can be implemented within a short time.


Is blocking UDP and TCP sufficient to prevent unwanted network activity?

You said "I want to be 100% sure that my machine only connects where and when I want it to", but do you have a strategy for covering what is sent?

Blocking ports is always a good idea, but to browse the web you'd want to be able to connect out on port 80, and at that point malware has a way to communicate out. You realise this, so you block all IP address destinations too except ones that you allow; great, that should do it. You like stackexchange and want to post there, so you open up to the SE servers, and you probably want Google and some others. At this point you are already vulnerable because malware could send data from your machine to an account on stackexchange, google, or elsewhere by logging in to a specific account and storing base 64'd encrypted data in the account profile for later extracting. Having content filtering might work, but it could be hard to configure. Of course you'll be on the lookout for your firewall alerting to transfers at a time you didn't expect, but smart malware could wait until it sees you sending or receiving data from stackexchange, for example, and send data at the same time to appear to be part of your traffic. Would you then notice the extra connection and traffic, or just assume that it was your browser opening up more than one connection, which it will tend to do anyway?

I've deliberately painted a bleak picture that while improbable, is entirely possible, and so the answer to your question has to be a "No". The only sure fire safe thing is never to connect it to the Internet.


Is it safer to run my own VPN server at home?

This is a question whom do you trust:

If you trust someone to offer the features, security, privacy... you expect from the VPN then you might use the offered VPN.
If you consider yourself firm enough in network security to run your own server you might do it.
If none of this is the case use the option with the lowest risk and somehow deal with the remaining risk.

  I am using a VPN because I am running a business and the threat is mitm attacks

Please note that a VPN does not fully protect you against MITM attacks. It  only provides a secure tunnel to some VPN endpoint and from than on you are again on your own. To secure the rest of the connection from the VPN endpoint to some server against MITM you would still need to use HTTPS or similar end-to-end encryption.


How to Investigate Wi-Fi Intrusion and where to look for evidence?

Most routers (even retail wifi units) have an admin screen that lists all the active clients that have been allocated an IP address by DHCP.  This usually lists the MAC address of the client too.

usually they look like this:

CLIENT NAME       IP ADDRESS       MAC ADDRESS
android_blah      192.168.1.10     AA-BB-CC-00-00-00
my_pc             192.168.1.11     DD-EE-AA-00-00-00

If you do not recognise the client names - then a handy tip is to take the first 3 octets of the MAC address and google them (e.g. AA-BB-CC) and this will tell you the manufacturer of the device which could help determine whether it really is inside or outside of your home.


NFC - Felica / NXP (Desfire EV1) or ACOS3 which is more secure?

DESfire before EV-1 (which was introduced in 2002) should indeed not be used any more and has not been recommended for use for more than five years. DESfire EV-1 (introduced ~2007) adds countermeasures against differential power analysis (which the non-EV-1 product lacked, leading to its eventual downfall), and AES-128. Since ~2014 there's even the newer DESfire EV-2 with better key management to delegate card space to third parties, proximity checks and better privacy options.

Felica is prevalent in Asia, but only added AES in around 2011.

I know nothing about ACOS except for its existence.

Note, if it isn't obvious: I'm biased towards DESfire EV-1, having worked with the cards in several projects.

For your basic problem of just storing data on a card that is to be read after authentication, disregarding all other things (authentication of data from the card, confidentiality of the data while in transit, etc.) it is likely that either system will work (and thus be indistinguishable).
If you eventually want more, you probably don't want a niche product like ACOS (except of course if it happens to hit your niche exactly), so DESfire or Felica. The latter is mostly documented in Japanese, so if that's a problem, that's a problem.


Pre-Requisites for Mutual Authentication

The server will indeed have and announce to the client (during SSL handshake) a list of trusted client CA, and the client will have to provide a client certificate signed by a CA on that list.

you said: In this way Server may be loaded with various Client Certificates?
I guess you meant "Client CA". The server wouldn't be pre-loaded with the actual client cert, unless it's a self-signed (root) cert.

At work, I see SSLMA used between technical components that need to be talking to each other for security-sensitive functionality. E.g. webapp1 -> webservice2, if webservice2 is doing something that you don't want to expose to everyone in the network. Webapp1 may have authenticated and authorized the end-user; but if webservice2 isn't set up to authenticate/authorize the end-users, it may suffice to have webservice2 accept a limited number of SSLMA clients; including webapp1.

On the internet, I haven't seen that much use of SSLMA (from browser to website), but there are cases, e.g. to log on to some government or banking websites. Typically, the client cert is then installed on a smartcard. I can think of only a few examples in Belgian context, not sure if that would help you.


How to investigate possible illegal access by a staff member to emails?

Anything we can say at this point is purely speculation, but based upon the information provided, I suspect the most likely explanation is inadvertent error, not malicious hacking.  Hacking is certainly possible, but it's not the first explanation I'd leap to.

For instance, maybe Steve inadvertently hooked up his email address to Dave's phone, or maybe Steve inadvertently typed his email password into Dave's phone while testing and the phone helpfully remembered it, or maybe there was some configuration error in setting up Dave's email on the Outlook server.

I definitely would not accuse Dave of hacking Steve's email based just upon the information provided here.  I would accuse Dave of poor judgement and poor ethics in forwarding Steve's emails to others and continuing to access Steve's email once Dave saw that he had access to Steve's email.

Update: Here are some additional suggestions on steps you could take to try to assess fault.

First, contact HR (and Security, if you have a Security department) immediately.  They should run the show.

Then, I would suggest you secure any logs from the Outlook Exchange you have, and analyzing them.

Third, I recommend that someone interview Dave and Steve to get their story.  For instance, I'd try to nail down the exact timing.  If Exchange keeps logs of when the email was accessed, you could then compare the timing and their stories against the timestamps in the Exchange logs.  I'd also ask Dave what he did to his phone and how he accessed Steve's emails.   I would ask Steve whether there is any chance that he might have entered his password into Dave's phone, even temporarily.  I'd also interview Steve to see if he made any configuration changes to Exchange that might have given Dave access to his email. And, I'd try to assess whether Steve has any motive to try to spin things or not (mutual dislike? bad blood?).  You probably want to have someone else (HR?) doing the interviewing.

Fourth, I recommend that you confiscate Dave's phone for examination without further delay. If it was a mistake, either Dave's phone may still have access to Steve's email, or Dave may be able to give some story about what happened that might explain why his phone no longer has access to Steve's email.

After you have assessed all the information available to you, if you're still not sure what happened, you could always consider trying an old interviewer's trick.  Have HR sit Dave down and say "Look, Dave, this is a very serious situation.  We confiscated your phone, we analyzed the logs on your phone and on the Exchange server, and we know just about everything about what happened.  The only thing we don't know is whether your actions were premeditated, or whether they were a spur-of-the-moment instance of poor judgement.  If your actions were premeditated, this a severe offense, and I may be forced to fire you.  On the other hand, if it was not pre-meditated, then that's still not good, but at least it would give me a basis for arguing on your behalf with the CEO.  So, if it was not premeditated, and if you are prepared to write out a full and complete confession right now and express remorse, I am prepared to argue for leniency in your case.  But don't try and snow me: if your confession differs in even one iota from the log information we already have, deal's off, and I'm going to be pissed.  So, what do you say, Dave?"  No guarantees that it'll work, though.


Is it possible to prevent a file type from being determined in a Linux system?

What you're looking for is called deniable encryption.

There are two forms of deniable encryption.  The first sort is "information-theoretic" deniable encryption: encryption where no mathematical analysis an attacker can perform can prove that a file is encrypted data and not a collection of random bytes.  The second sort is "real-world" deniable encryption: encryption where you can do something to convince an attacker with a $5 wrench that your file does not contain the stolen Death Star plans.

Everyone will offer you the first sort.  The problem with it is that normal people do not carry around large quantities of random bytes -- finding such a file is prima facie evidence that encryption is in use.  The second sort does not exist, and may be impossible -- you need encryption that lets you prove a negative.


Is it possible to do research in both Computer Architecture and Security

I think the most interesting work, academically, is at Cambridge (check https://www.cl.cam.ac.uk/research/security/capsicum/documentation.html)

ARM is doing research into this, as is Intel and Apple, but there are fewer citations to start digging into.


FileZilla per se isn't inherently insecure. Yes, it's storing passwords in plaintext, but the alternatives are only slightly more secure. You see, encrypting the credentials requires an encryption key which needs to be stored somewhere. If a malware is running on your user account, they have as much access to what you (or any other application running at the same level) have. Meaning they will also have access to the encryption keys or the keys encrypting the encryption keys and so on.

Your best option here is to disable password storage in FileZilla

Then start using KeePass to store your account credentials. There are also many guides on the Internet about how to integrate KeePass with FileZilla. Doing this, you're storing the encryption key somewhere where malware don't have access; you're storing the encryption key (or rather, the password from which the encryption key is derived) in your brain.

Finally (and perhaps this is a bit outside the scope of your question), please make sure you move away from FTP in favor of SFTP.


Logically, Is it possible to implement a method that proxy server is not able to interpret passing data to Telegram Server at all?

That's not specific to Telegram. If you are using a HTTP or SOCKS proxy to visit site with HTTPS you still have end-to-end encryption, i.e. the proxy sees only encrypted traffic. It is different when having a SSL intercepting proxy which one usually finds in companies but also as local proxy in antivirus products. In this case the proxy will decrypt end re-encrypt the traffic in order to analyze it. But this would also mean that your client is explicitly trusting the proxy to do this, see Does https prevent man in the middle attacks by proxy server?
 for more details about SSL interception.

But even if an SSL intercepting proxy is used it would still be possible to add yet another level of end-to-end encryption on top of it with fixed information of what kind of end-system is expected, i.e. similar to certificate pinning. Even an SSL intercepting proxy will only see the encrypted traffic and might decide to pass it or block it but will not be able to look further into it.


Open source firmware as mitigation against firmware persistent malware?

No, open-source firmware does not provide "greater protection against firmware malware" just because it's "open". It can still have the same vulnerabilities as the closed-source firmware (see e.g. BARing the System: New Vulnerabilities in Coreboot & UEFI based Systems).

It does lessen your chance of infection significantly just because your firmware is not of a common variety and not a part of monoculture of the few BIOS makers (see How Many Million BIOSes Would you Like to Infect? for background on the issue), in the same way as using Mac or Linux makes you immune from Windows viruses (but Mac and Linux viruses do exist).

However, open-source firmware may implement additional protections which make it more resilient against infections. For example, Chromebooks use signed firmware and almost any modifications of it will make machine unbootable (unless you enable developer mode which requires physical access). Note that the same feature is offered by the recent Intel BootGuard (except it does not have developer mode - once enabled, the signing checks can't be removed).

P.S. Please note that BadBIOS has not been confirmed to be real. There were a few proof-of-concept rootkits presented by researchers and there was some stuff in the leaked Equation Group files which targeted BIOSes of some network appliances but AFAIK the only confirmed in-the-wild BIOS infection was Mebromi which only targets pretty old Award BIOS versions. I would suggest you to think about your threat model and concentrate on the more realistic threats first (e.g. phishing/social engineering).


Yes, this approach make sense. There's even a Linux distribution called Qubes OS that does exactly this, with extra care taken so that applications cannot exit their VM isolation.

I would recommend you to read their blog articles if you want to learn more on the subject.


Will using SSL to secure Wordpress admin area only still actually be secure?

Generally speaking, that's true.   Authenticated requests (requests that contain cookies or other state information that identifies a specific user) must only be made via HTTPS for that data to remain reasonably secure.

However, in this particular instance, there may be a potential alternative, which is to set the "secure" attribute on the cookies, and treat the users as unauthenticated on non-HTTPS pages.   If they don't need to be authenticated on the non-admin pages, then setting the secure flag on the cookies will insure that they aren't sent along with requests to non-admin pages that aren't protected by SSL.

So, if they cookies need to be sent with every request, then every request needs to be HTTPS.   If they don't, then you're equally safe simply making sure that the cookies aren't sent except when the request is protected by SSL.


One of the easiest ways to do this is to use WireShark and setup filter colors for video encoding streams. This way you only have to look at the colors of the current traffic to see the video.

You could also colorize your ip traffic in green and video streams from other IP's in another color such as red.

Note: there are several other ways to do this in WireShark.

https://www.wireshark.org


How can I prevent forwarding a manipulated email?

Email is unsafe -- deal with it.

Email can be made safe for an adequately defined value of "safe", through the use of signatures (S/MIME or OpenPGP). This is not as easy as it seems (I mean, it does not look easy, but in reality it is worse). The cornerstone of the system is that unsigned emails should be rejected automatically; human users should never see them at all, because if they read them, they will always believe them a little, regardless of how much you may have explained to them how insecure and unsafe plain emails are. Therefore, switching to signed emails is like a big jump into the unknown. In practice, it is essentially a way to break emails (or to induce users to switch to gmail...).

What you can do is to educate and then to educate again:

The smooth education: explain to your users how untrustworthy email is as a medium. Show how easy it is to forge an email (e.g. with this answer). Try to prevent the "wizardry effect" which makes most human beings lose common sense as soon as a computer is involved (as Clarke was putting it, computers are beyond the "magical horizon" of most people -- solution is to make them understand how a computer works). As a bonus, this makes the users more resilient to phishing.
The less smooth education: let all the might of the Law fall on wannabe fraudsters. Have it known that the slightest phony game with email is a shooting offense; the guilty will be fired, jailed, shot and flogged (not necessarily in that order). The idea is to make faking emails not worth it. This works well: this is how the non-computer world deals with handwritten signatures, and it has done so for several centuries.


How to correctly secure a ssh session against MITM attack?

Make sure you pay attention to the warnings about changes to the server's public key.  If you get a warning like this, say "no" and check the public key fingerprint through out-of-band means; don't say "yes" unless you have verified the public key fingerprint somehow.
If you never connect to new hosts, you can set
StrictHostKeyChecking yes

in your ~/.ssh/config configuration file (or in /etc/ssh/ssh_config).  However this may be annoying if you frequently connect to new machines.
Read the section VERIFYING HOST KEYS of the ssh man page.
Read How do RSA fingerprints protect from MITM attacks? on this site.
Use a SSH private key, not a password, to authenticate.
If you are in control of your own infrastructure, you can look into setting up ssh certificates for both hosts and users. This allows the ssh client to verify the identity of the ssh server.  This may be the best solution against man-in-the-middle attacks, as it eliminates the need for users to check fingerprints carefully.  Realistically, many users probably won't bother to check, so ssh certificates may be a more usable and more reliable defense.


First open the command prompt ,cd to particular partition  and run this

attrib -s -h /s /d *

Then you need to open that partition using windows explorer. You must not double click on hard disk. Use left pane and navigate to particular partition.

Then delete all other files in your hard disk that you do not need. Do same for C drive.

If you can not delete some files

Start -> run

type 'msconfig' and enter

Stop all services and restart and do the all above steps.

Finally you need to edit your registry. follow below steps

go to run
type regedit.
go that path:- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\
Advanced\Folder\Hidden\SHOWALL
4.Look at the CheckedValue key( in right side).This should be a DWORD key. If it isn't, delete the key. Create a new key called "CheckedValue" as a DWORD (hexadecimal) with a value of 1.

Restart your machine... This should work.

FYI

start -> run
gpedit.msc

And TurnOff Autoplay for all devices. This will help you to protect from viruses.

And do not double click on hard disks. Always try to use explorer


Imitation Gmail account created - what's the threat?

There are three possibilities that I see:

honest mistake. John Q. Samenameasyourparents set up an account, came up with your parents' name, was warned by Google and suggested "...51" as an alternative, blindly clicked "Yes, yes" without reading, re-entered your parents' account as backup address (never do that), and thus created an "orphan" account he will never be able to access.
the above is what someone wants you(r parents) to believe. The account is not orphan but is linked to another. By using it as a "backup" account or by mistakenly switching to your 'main' account, you may be giving unknown third parties access to some information. Of course this has a very low chance of happening (one in ten?), but a phisher might think that by creating one thousand such accounts, he may be gaining itself one hundred fat, unsuspecting marks. The attempt against your parents' account having come somewhat close to succeeding might have prompted someone to file them under "potential victims for a new scheme".
someone has attempted to create a fake account to pose as your parents. This can be used in connection to (b) above: should someone reply to that account, once set up, he would really get in contact with your parents. This would indicate that the unknown someone has also available a list of some of your parents' contact. I've seen a similar scheme in which several friends of mine (from a mailing list) would receive a heartbreaking email from lserni@gmailll.com in which "I", having been robbed in some faraway country and having no wallet, no documents and no cellphone (so don't call me to verify!), am now in dire need of a trusted friend to wire me some money c/o a money transfer parlor in Upper Nowherestan. The email was quite beautifully crafted too.

In all these cases I'd simply forward everything to Google. They can check what happened (i.e. were other accounts created? Did MaryAndJohn@gmail.com follow the unsuccessful creation of JohnAndMary@gmail.com? Were several similar accounts created from the same subnet in the same time interval?... and so on) and take appropriate measures.


You should use TLS to transmit securely over the network. If the data is indeed JSON, then it makes the most sense for the server to simply be a webserver and you would use TLS in the form of HTTPS to secure the communication.

For authentication, don't roll your own RSA based system.  TLS automatically gives you server authentication.   If you need client authentication as well, what you choose will depend on the application's needs.  If device based client auth is needed, client certs would be one way to handle this.

Additionally, don't wait until you've built the system to talk the the hospital's IT security staff.   You should talk to them as soon as you're finished with your intended design, at the latest.


So why SOCKS proxies haven't forced HTTPS proxies out yet? When HTTP proxy is better?

Convenience, HTTP proxies handle HTTPS connections transparently; by creating a tunnel and through the HTTP CONNECT method.  For any non-TLS connections, it will forward HTTP requests just as well.

Since the majority of "legitimate" traffic is HTTP(s) anyway (i.e: a hotel / airport / ... is more likely to let you do http(s) traffic), it's more riskier for a company to allow sock proxies.  This will allow people to use their connection to perform outbound connections (spam, bruteforce attacks, ...)


John The Ripper Error: No password hashes loaded when cracking a zip file in kali linux

You need to update to the latest John the Ripper.  I experienced the same error as you with john 1.8.0 but when I downloaded the latest bleeding edge release from Github (1.9.0-jumbo-1+bleeding-d29f456a4 2021-01-20) I was able to crack the same file:
$ ./john passwordFile.txt
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Warning: OpenMP is disabled; a non-OpenMP build may be faster
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:./password.lst
techno           (Traffic.zip)
1g 0:00:00:00 DONE 2/3 (2021-01-23 16:44) 20.00g/s 1298Kp/s 1298Kc/s 1298KC/s frodo..barbara
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
$

This is not uncommon.  "Run the latest bleeding edge" is a standard prescription for fixing issues with John the Ripper.  I followed the instructions in john/doc/INSTALL-UBUNTU which explicitly tell how to grab the bleeding distribution; they're probably a good starting point for Kali (although the names of some prerequisite packages may differ).


It looks like you installed Cybereason RansomFree.

This writes two folders with 'random' file names to each of your partitions, and one to the desktop labeled This folder protects against ransomware. Modifying it will reduce protection* (which you will only see if you have configured Windows to show hidden/system files).

The program monitors these folders for ransomware activity, and regularly rewrites them. The file contents are gibberish, you can't open one of these .xls files in Excel, etc.

So, not a virus.
Here is a sample folder from my drive:

* Actual text changes with version. They have been updating the program several times over the past few weeks.


You cannot hide or encrypt your CSRF token, as it is usually passed to the web application in HTTP GET or HTTP POST request and it should be present on HTML page (or generated by JavaScript, which is basically the same).

CSRF-token is only one way to protect your web application against auto submissions (aka CSRF attack). Its usage is recommended when dealing with not very sensitive data. If you want to protect your web application against CSRF with CSRF token, I recommend you generate a new token at least every 15-20 minutes, so it cannot be easily brute-forced.

In many real-world implementations CSRF token is bound to session identifier. The same advice is valid for session identifier as well.

As for SOP, it should not allow by default to access elements within iframes. However, there have been vulnerabilities in many browsers in the past, which allowed this behavior.

The bottom line – you do not have to hide CSRF token. Instead, generate a new one once in a while. For very sensitive actions use additional means of user verification, e.g. request for user's password or use OTP.


Where do TLS clients fetch intermediate CA certificates from?

They are all sent together by the server

All certificates, except for the root certificate, are sent together as one bundle.

Technically, you may include the root certificate as well, but it will be ignored by the client.

If the server only sends the "leaf" certificate, then it depends on the browser if they are able to somehow get the missing intermediate certificates. One way, for instance, is for them to cache intermediate certificates from previous connections. Chrome uses the Authority Information Access extension to locate missing intermediate certificates that way.

If all of these attempts fail, and the intermediate certificates are not available, then the certificate verification will fail.