Tag Info

New answers tagged

2

I do not think there is a significant security advantage for using it in an HTTP header (not counting the URL which is sent in the request line that starts the HTTP request, where you have to be more cognizant of it being logged in your browser history or server logs) vs being in a POST request body. The advantage of sending keys in an "Authorization header ...


2

If the transport itself is secured (i.e. https) an attacker can not sniff the data. But it might be logged at the server side and the server might later be compromised or some security leak might cause the log files to be publicly visible. Such log files usually contain the URL and they might contain other lines from the headers like User-Agent, Referer and ...


0

According to tech support for Niagara AX, "HTTPS Tunneling is not supported". This contradicts what I have heard from other sources, so while I will put this as the "official" answer to my question, I may update it if other information becomes available. In other words, the point of my question, namely to find out whether certain settings or file formats ...


0

This is mostly secure. To intercept localhost traffic an attacker would need root privileges and at this point you've already lost as the attacker can also read and modify memory at will - no amount of cryptography will help you as the attacker will get your confidential data straight out of memory. The only issue I see is that you can't prove it's indeed ...


0

There are several technologies involved in creating a secure connection (the network protocol stack). Each layer solves its own part of the job to make connections work. The parts of the stack that are relevant to your questions are: HTTPS TCP IP You can notice that HTTPS sits on top of TCP, which works on top of IP. HTTPS cannot change how underlying ...


2

Both SSH and HTTPS (relying on SSL or TLS) use encryption, but are based on an established TCP/IP existing connection. This means that even if the content is opaque, all TCP/IP information are in clear and available to someone sniffing your network. TCP/IP information includes IP address of each peer, port numbers used. This gives a good hint about protocol ...


0

It depends entirely on the topology of the network used to connect your computer to the server. If your computer is connected to the server directly using an ethernet cable or similar connection, and those computers and cable are inside a secure room and you have made sure that nobody saw you entering the room then NO, nobody can know you have connected ...


6

Yes. This is called "Traffic Analysis". Broadly speaking, the useful information that can be obtained is who you're talking to, and when. So if you're ssh'ed into a server and the packets look like someone typing, it then looks like you're up and actively engaged in some activity with that server. The volume of the data going back and forth can be ...


2

Sure, they can. A proper encryption is supposed only to hide the content, but is not expected to hide: parties involved in the communication size of data exchanged timing of packets (anything else) Moreover, some data may be leaked from the initial handshake. For example, HTTPS with SNI leaks the domain you are connecting to in plaintext even if the ...


7

They can. In order to establish a secure HTTPS connection a handshake must happen between you, (the client, i.e. your browser or any other application) and the server. Any data sent within the handshake is not encrypted. About the risks, it's a broad topic to discuss. The plain information that you are connecting to some public server (Facebook, Gmail, ...


1

As @Philipp states, any URI may have a query string, regardless of the HTTP method (GET, POST, PUT, ...) it is used with. The RFCs do not, in general, explicitly discuss query strings, even when discussing methods like GET where we expect to see them. A rare explicit mention is in RFC 2068: some applications have traditionally used GETs and HEADs ...


1

According to RFC 3986 - Uniform Resource Identifier the query component is allowed for any URI regardless of the used protocol. That means it is not only allowed for any HTTP method (what you call "request type"), but even for any other protocol which uses URIs, like for example ftp.


0

As the commentators suggested you correctly, you will need to use the HttpOnly fla as a solution. But I just want to add a note regarding the right comments you received about HttpOnly flag. In fact, if a client of your website uses a Mozilla Firefox browser of version before 3.0.6 (Bug 380418: XMLHttpRequest allows reading HTTPOnly cookies) and/or ...


1

All an authenticated HTTPS connection does is validate that if https://www.example.com is shown in the address bar, that you are in fact connected to www.example.com. The certificate does not certify that www.example.com is not malicious in any way. An Extended Validation Certificate with a green highlight shown around the address bar will allow you to know ...


0

The communication between you (your browser) and the server using HTTPS is secure in that case (of course, we suppose you are not a victim of some scenarii like MITM attack). The certificate ensures you are communicating with the right website, nothing more. But HTTPS is not responsible of the nature of the content of this communication: by nature of the ...


0

if the website use https you can theorically be sure (day 0 exploit excluded) that you are visiting the website you see in the url and that nobody can see your exchange . This doesn't mean the site isn't malicious, corrupted or insecure in the way that can harm you.


0

All an authenticated HTTPS connection does is validate that if https://www.example.com is shown in the address bar, that you are in fact connected to www.example.com. The certificate does not certify that www.example.com is not malicious in any way. An Extended Validation Certificate with a green highlight shown around the address bar will allow you to know ...


5

Session state within an application should ideally be managed server-side from a security perspective. So in terms of expiry a list of active sessions should be stored and they should be removed from the server after an agreed period of inactivity (exactly what this would be depends on the application sensitivity, user base etc) The application should also ...


3

I originally made a comment on some answer, but I think that the person asking the question is confusing anonymity with IP spoofing, which are different beasts altogether, so I'll go into a bit more detail. In a typical environment, you can not spoof an IP address for an HTTP request, and this is because an HTTP request is running over the TCP stack. ...


3

When i read your question, TOR browser immediately came to my mind, the idea behind tor browser is "bouncing your communications around a distributed network of relays run by volunteers all around the world". this not only changes your IP address every a couple of minutes (please check specific timing in the browser), but with one click (onion button > new ...


10

There's a number of ways that you could achieve this As @raz says in comments use Tor. The Tor network is designed to anonymise Internet traffic so this would fit your bill quite well. Using something like Tails OS could be an easy way to get started for you in that line. As @zviad-gabroshvili says use a proxy. there are a wide range of proxy services ...


4

I cant create a comment, so this is my two cents. You can of course send a HTTP request under a different IP number (other than yourself, "anonymous"), using NMAP. But the one down side would be that you will never get your HTTP request back, because if the server responds it will respond to the spoofed IP address. Unless you set the IP address to some ...


6

If you are running Linux, you can install proxychains by opening terminal(Ctrl+Alt+T) and in terminal type sudo apt-get install proxychains and press Enter, second option you can use is that use http_proxy. Check proxy list here: http://proxylist.hidemyass.com/search-1299183#listable In terminal type: export http_proxy="http://x.x.x.x:port", press Enter. To ...


0

You don't need to do this; this is already solved by the SSL/TLS handshake. The SSL/TLS handshake goes a bit further, in that it not only establishes a secret by using both the public and private keys of both parties, but also uses a certificate to establish that the server is who it reports to be - preventing a man-in-the-middle attack. A quick, more ...


1

I understand the contradiction (if we may call it so) you highlighted. So I read both (some parts of the specification related to the private option) and the article. I rather searched about the original article where the bug was first mentioned. In that article, it is stated: It was reported that multiple meta.wikimedia.org users received the same ...


0

Part I - How could Facebook find out your fake account? I tried to create an account through two different ways: My laptop by using Tor Browser - Result: No identity check nor references to my real Facebook account. VM using NAT, Firefox and VPN - Result: No identity check nor references to my real Facebook account. By reading your description ...


1

Actually I started to comment until I guessed my comment is too long ... anyway: Whatever the settings methods you used to deploy SOCKS5 that you mentioned in your comments to hide your IP, surely Facebook does not rely on IP addresses to identify its users because IP addresses could be the same if the users are, for instance, behind a corporate firewall, ...


-1

A couple of vectors that come to mind: You have not hidden your public IP (unless you are using Tor) Facebook probably has a cookie on your device, linking previous logins. In fact, the latter information is good enough to identify you pretty well.



Top 50 recent answers are included