What attacks are made possible by public release of my web history?
up vote
41
down vote
favorite
Assume that my internet history is made public (accidentally or on purpose). And this release is over 24 hours since the visits were made.
Also assume that there aren't an embarrassing sites on there: there isn't any blackmail potential.
(My most embarrassing page visited in the last week is actually the TV tropes page for my little pony, for which I have a valid reason and a witness).
What potential attacks does this allow? I'm mildly concerned about seeing massive links like:
https://kdp.amazon.com/en_US/ap-post-redirect?openid.assoc_handle=amzn_dtp&aToken=Atza%7CIwEBIO9mWoekr9KzK7rH_Db0gp93sewMCe6UcFPm_MbUhq-jp1m7kF-x0erh6NbjdLX3bm8Gfo3h7yU1nBYHOWso0LiOyUMLgLIDCEMGKGZBqv1EMyT6-EDajBYsH21sek92r5aH6Ahy9POCGEplpeKBVrAiU-vl3uIfOAHihKnB5r2yXPytFCITXM70wB5HBT-MIX3F1Y2G4WfWA-EgIfZY8bLdLangmgVq8hE61eDIFRzcSDtAf0Sz7_zxm1Ix8lV8XFBS8GSML9YSwZ1Gq6nSt9pG7hTZoGQns9nzKLk7WpAWE8RazDLKxVJD-nDsQ9VdBJe7JZJtD7c77swkYneOZ5HXgeGFkGhKsMnP7GSYndXhC_PqzY251iDt0X7e5TWvh86WZA0tG2qZ_lyIagZtB3iw&openid.claimed_id=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.identity=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.mode=id_res&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.op_endpoint=https%3A%2F%2Fwww.amazon.com%2Fap%2Fsignin&openid.response_nonce=2018-12-11T13%3A46%3A52Z4004222742336216632&openid.return_to=https%3A%2F%2Fkdp.amazon.com%2Fap-post-redirect&openid.signed=assoc_handle%2CaToken%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2CsiteState%2Cns.pape%2Cpape.auth_policies%2Cpape.auth_time%2Csigned&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fnone&openid.pape.auth_time=2018-12-11T13%3A46%3A52Z&openid.sig=5cx5iHjeLyWTTA9iJ%2BucszunqanOw36djKuNF6%2FOfsM%3D&serial=&siteState=clientContext%3D135-4119325-2722413%2CsourceUrl%3Dhttps%253A%252F%252Fkdp.amazon.com%252Fbookshelf%253Flanguage%253Den_US%2Csignature%3DgqJ53erzurnmO1SPLDK1gLwh9%2FUP6rGUwGF2uZUAAAABAAAAAFwPv8dyYXcAAAAAAsF6s-obfie4v1Ep9rqj
in my history and worrying that secure information might be passed in a URL somewhere.
I am aware that this makes it easier to impersonate my identity, I'm mostly interested in the leakage of information via the URL itself.
web-browser url
New contributor
add a comment |
up vote
41
down vote
favorite
Assume that my internet history is made public (accidentally or on purpose). And this release is over 24 hours since the visits were made.
Also assume that there aren't an embarrassing sites on there: there isn't any blackmail potential.
(My most embarrassing page visited in the last week is actually the TV tropes page for my little pony, for which I have a valid reason and a witness).
What potential attacks does this allow? I'm mildly concerned about seeing massive links like:
https://kdp.amazon.com/en_US/ap-post-redirect?openid.assoc_handle=amzn_dtp&aToken=Atza%7CIwEBIO9mWoekr9KzK7rH_Db0gp93sewMCe6UcFPm_MbUhq-jp1m7kF-x0erh6NbjdLX3bm8Gfo3h7yU1nBYHOWso0LiOyUMLgLIDCEMGKGZBqv1EMyT6-EDajBYsH21sek92r5aH6Ahy9POCGEplpeKBVrAiU-vl3uIfOAHihKnB5r2yXPytFCITXM70wB5HBT-MIX3F1Y2G4WfWA-EgIfZY8bLdLangmgVq8hE61eDIFRzcSDtAf0Sz7_zxm1Ix8lV8XFBS8GSML9YSwZ1Gq6nSt9pG7hTZoGQns9nzKLk7WpAWE8RazDLKxVJD-nDsQ9VdBJe7JZJtD7c77swkYneOZ5HXgeGFkGhKsMnP7GSYndXhC_PqzY251iDt0X7e5TWvh86WZA0tG2qZ_lyIagZtB3iw&openid.claimed_id=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.identity=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.mode=id_res&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.op_endpoint=https%3A%2F%2Fwww.amazon.com%2Fap%2Fsignin&openid.response_nonce=2018-12-11T13%3A46%3A52Z4004222742336216632&openid.return_to=https%3A%2F%2Fkdp.amazon.com%2Fap-post-redirect&openid.signed=assoc_handle%2CaToken%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2CsiteState%2Cns.pape%2Cpape.auth_policies%2Cpape.auth_time%2Csigned&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fnone&openid.pape.auth_time=2018-12-11T13%3A46%3A52Z&openid.sig=5cx5iHjeLyWTTA9iJ%2BucszunqanOw36djKuNF6%2FOfsM%3D&serial=&siteState=clientContext%3D135-4119325-2722413%2CsourceUrl%3Dhttps%253A%252F%252Fkdp.amazon.com%252Fbookshelf%253Flanguage%253Den_US%2Csignature%3DgqJ53erzurnmO1SPLDK1gLwh9%2FUP6rGUwGF2uZUAAAABAAAAAFwPv8dyYXcAAAAAAsF6s-obfie4v1Ep9rqj
in my history and worrying that secure information might be passed in a URL somewhere.
I am aware that this makes it easier to impersonate my identity, I'm mostly interested in the leakage of information via the URL itself.
web-browser url
New contributor
1
Is it just your browser history or it a complete account/host compromise? It matters because, while your browser history might not provide much (unless you're into obscure porn), if they had access to your computer/profile, cookies, key loggers, screen scrapers are a whole different ballgame.
– thepip3r
yesterday
2
@thepip3r browser history only - and actually in this use case: url and timestamp pairs.
– Joe
yesterday
3
I can't believe that nobody mentioned spearphishing yet. With recent information of what you look at an attacker could easily send fake invoices or otherwise create very undetectable phishing mails.
– BlueWizard
10 hours ago
add a comment |
up vote
41
down vote
favorite
up vote
41
down vote
favorite
Assume that my internet history is made public (accidentally or on purpose). And this release is over 24 hours since the visits were made.
Also assume that there aren't an embarrassing sites on there: there isn't any blackmail potential.
(My most embarrassing page visited in the last week is actually the TV tropes page for my little pony, for which I have a valid reason and a witness).
What potential attacks does this allow? I'm mildly concerned about seeing massive links like:
https://kdp.amazon.com/en_US/ap-post-redirect?openid.assoc_handle=amzn_dtp&aToken=Atza%7CIwEBIO9mWoekr9KzK7rH_Db0gp93sewMCe6UcFPm_MbUhq-jp1m7kF-x0erh6NbjdLX3bm8Gfo3h7yU1nBYHOWso0LiOyUMLgLIDCEMGKGZBqv1EMyT6-EDajBYsH21sek92r5aH6Ahy9POCGEplpeKBVrAiU-vl3uIfOAHihKnB5r2yXPytFCITXM70wB5HBT-MIX3F1Y2G4WfWA-EgIfZY8bLdLangmgVq8hE61eDIFRzcSDtAf0Sz7_zxm1Ix8lV8XFBS8GSML9YSwZ1Gq6nSt9pG7hTZoGQns9nzKLk7WpAWE8RazDLKxVJD-nDsQ9VdBJe7JZJtD7c77swkYneOZ5HXgeGFkGhKsMnP7GSYndXhC_PqzY251iDt0X7e5TWvh86WZA0tG2qZ_lyIagZtB3iw&openid.claimed_id=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.identity=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.mode=id_res&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.op_endpoint=https%3A%2F%2Fwww.amazon.com%2Fap%2Fsignin&openid.response_nonce=2018-12-11T13%3A46%3A52Z4004222742336216632&openid.return_to=https%3A%2F%2Fkdp.amazon.com%2Fap-post-redirect&openid.signed=assoc_handle%2CaToken%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2CsiteState%2Cns.pape%2Cpape.auth_policies%2Cpape.auth_time%2Csigned&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fnone&openid.pape.auth_time=2018-12-11T13%3A46%3A52Z&openid.sig=5cx5iHjeLyWTTA9iJ%2BucszunqanOw36djKuNF6%2FOfsM%3D&serial=&siteState=clientContext%3D135-4119325-2722413%2CsourceUrl%3Dhttps%253A%252F%252Fkdp.amazon.com%252Fbookshelf%253Flanguage%253Den_US%2Csignature%3DgqJ53erzurnmO1SPLDK1gLwh9%2FUP6rGUwGF2uZUAAAABAAAAAFwPv8dyYXcAAAAAAsF6s-obfie4v1Ep9rqj
in my history and worrying that secure information might be passed in a URL somewhere.
I am aware that this makes it easier to impersonate my identity, I'm mostly interested in the leakage of information via the URL itself.
web-browser url
New contributor
Assume that my internet history is made public (accidentally or on purpose). And this release is over 24 hours since the visits were made.
Also assume that there aren't an embarrassing sites on there: there isn't any blackmail potential.
(My most embarrassing page visited in the last week is actually the TV tropes page for my little pony, for which I have a valid reason and a witness).
What potential attacks does this allow? I'm mildly concerned about seeing massive links like:
https://kdp.amazon.com/en_US/ap-post-redirect?openid.assoc_handle=amzn_dtp&aToken=Atza%7CIwEBIO9mWoekr9KzK7rH_Db0gp93sewMCe6UcFPm_MbUhq-jp1m7kF-x0erh6NbjdLX3bm8Gfo3h7yU1nBYHOWso0LiOyUMLgLIDCEMGKGZBqv1EMyT6-EDajBYsH21sek92r5aH6Ahy9POCGEplpeKBVrAiU-vl3uIfOAHihKnB5r2yXPytFCITXM70wB5HBT-MIX3F1Y2G4WfWA-EgIfZY8bLdLangmgVq8hE61eDIFRzcSDtAf0Sz7_zxm1Ix8lV8XFBS8GSML9YSwZ1Gq6nSt9pG7hTZoGQns9nzKLk7WpAWE8RazDLKxVJD-nDsQ9VdBJe7JZJtD7c77swkYneOZ5HXgeGFkGhKsMnP7GSYndXhC_PqzY251iDt0X7e5TWvh86WZA0tG2qZ_lyIagZtB3iw&openid.claimed_id=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.identity=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.mode=id_res&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.op_endpoint=https%3A%2F%2Fwww.amazon.com%2Fap%2Fsignin&openid.response_nonce=2018-12-11T13%3A46%3A52Z4004222742336216632&openid.return_to=https%3A%2F%2Fkdp.amazon.com%2Fap-post-redirect&openid.signed=assoc_handle%2CaToken%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2CsiteState%2Cns.pape%2Cpape.auth_policies%2Cpape.auth_time%2Csigned&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fnone&openid.pape.auth_time=2018-12-11T13%3A46%3A52Z&openid.sig=5cx5iHjeLyWTTA9iJ%2BucszunqanOw36djKuNF6%2FOfsM%3D&serial=&siteState=clientContext%3D135-4119325-2722413%2CsourceUrl%3Dhttps%253A%252F%252Fkdp.amazon.com%252Fbookshelf%253Flanguage%253Den_US%2Csignature%3DgqJ53erzurnmO1SPLDK1gLwh9%2FUP6rGUwGF2uZUAAAABAAAAAFwPv8dyYXcAAAAAAsF6s-obfie4v1Ep9rqj
in my history and worrying that secure information might be passed in a URL somewhere.
I am aware that this makes it easier to impersonate my identity, I'm mostly interested in the leakage of information via the URL itself.
web-browser url
web-browser url
New contributor
New contributor
edited yesterday
The Guy with The Hat
202113
202113
New contributor
asked yesterday
Joe
30837
30837
New contributor
New contributor
1
Is it just your browser history or it a complete account/host compromise? It matters because, while your browser history might not provide much (unless you're into obscure porn), if they had access to your computer/profile, cookies, key loggers, screen scrapers are a whole different ballgame.
– thepip3r
yesterday
2
@thepip3r browser history only - and actually in this use case: url and timestamp pairs.
– Joe
yesterday
3
I can't believe that nobody mentioned spearphishing yet. With recent information of what you look at an attacker could easily send fake invoices or otherwise create very undetectable phishing mails.
– BlueWizard
10 hours ago
add a comment |
1
Is it just your browser history or it a complete account/host compromise? It matters because, while your browser history might not provide much (unless you're into obscure porn), if they had access to your computer/profile, cookies, key loggers, screen scrapers are a whole different ballgame.
– thepip3r
yesterday
2
@thepip3r browser history only - and actually in this use case: url and timestamp pairs.
– Joe
yesterday
3
I can't believe that nobody mentioned spearphishing yet. With recent information of what you look at an attacker could easily send fake invoices or otherwise create very undetectable phishing mails.
– BlueWizard
10 hours ago
1
1
Is it just your browser history or it a complete account/host compromise? It matters because, while your browser history might not provide much (unless you're into obscure porn), if they had access to your computer/profile, cookies, key loggers, screen scrapers are a whole different ballgame.
– thepip3r
yesterday
Is it just your browser history or it a complete account/host compromise? It matters because, while your browser history might not provide much (unless you're into obscure porn), if they had access to your computer/profile, cookies, key loggers, screen scrapers are a whole different ballgame.
– thepip3r
yesterday
2
2
@thepip3r browser history only - and actually in this use case: url and timestamp pairs.
– Joe
yesterday
@thepip3r browser history only - and actually in this use case: url and timestamp pairs.
– Joe
yesterday
3
3
I can't believe that nobody mentioned spearphishing yet. With recent information of what you look at an attacker could easily send fake invoices or otherwise create very undetectable phishing mails.
– BlueWizard
10 hours ago
I can't believe that nobody mentioned spearphishing yet. With recent information of what you look at an attacker could easily send fake invoices or otherwise create very undetectable phishing mails.
– BlueWizard
10 hours ago
add a comment |
6 Answers
6
active
oldest
votes
up vote
42
down vote
accepted
Your question might be more undefined than you realise. Any kind of data can be passed using URL parameters. Usernames, passwords, authentication tokens, settings, form data, or anything the web developer chooses. It's not always good practice to use URL parameters to for this, but it is always possible.
And it's entirely up to each individual web developer on each individual page (not just site) as to what might be exposed and when. So you might not be able to predict what might be exposed.
So, to answer your question, in the worst case, you could experience a complete and utter disclosure of any amount of personal data including credentials.
By request, I did a search for the practice of "passwords in URL parameters" and restricted results to this year. Here's one of the top hits:
https://answers.splunk.com/answers/622600/how-to-pass-username-and-password-as-a-parameter-v.html
That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this.
Here is OWASP's official page on this vulnerability:
The parameter values for 'user', 'authz_token', and 'expire' will be
exposed in the following locations when using HTTP or HTTPS:
Referer
Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing
4
The only thing I'd add to this is that the problem is also worse because while you're correct that any data can be passed via URL, the problem is compounded by the fact that what information is passed via a URL and whether and how it is secured is up to each individual company you're visiting and furthermore, the standards of the web programmers who developed each page. So you could never say by looking at one URL that there wasn't any sensitive data passed--you couldn't even say that about different URLs from the same site...
– thepip3r
yesterday
3
and even if passwords aren't passed in the query string, if the session token is, you'd better hope that the developers restricted it to a single IP address and limited time validity...
– Ben Voigt
yesterday
1
"That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this." That's misleading—your link is to a community forum, where two Splunk users are discussing doing this unsafely. It's not a demonstration of Splunk itself passing sensitive information in URL parameters.
– Justin Lardinois
11 hours ago
1
@JustinLardinois not misleading at all - Splunk actually offers the settingenable_insecure_login
Splunk is actually passing sensitive information
– schroeder♦
10 hours ago
1
@schroeder From that answer, though, it looks like it's something that's disabled by default.
– Justin Lardinois
5 hours ago
|
show 2 more comments
up vote
12
down vote
Quite a bit actually:
- Extortion based off content
- Mapping systems that are not public
- Sensitive parameters in certain requests
- Personal information
Extortion
That search of yours that may be embarrassing and taken out of context. A WebMD search for a medical condition you don't want made known to co-workers for example. A search that was best done in incognito mode you forgot about.
Mapping systems that are not public
How about your works intranet site or that production web portal, well those names are going to pop up in your history now and if its something like Jenkins - thats a great candidate for a DNS rebind attack.
Sensitive parameters in certain requests
If you visit a site that just does the internet wrong and the parameter contains an API key, password, credential or just an account ID well that is captured and can be used now.
Personal information
I see you've been searching for holidays in March for 2 weeks - that would be a great time to break in to your house or impersonate you. Looking for an engagement ring well that sounds like something worth stealing. You did a google map from your address to another location?
add a comment |
up vote
7
down vote
One of the threats I'd like to mention that has not been named yet is de-anonymization.
The URIs in your history could leak information about your user accounts on different sites - for instance if you constantly check your own profile on social media sites. If you use some web services anonymously and others under your real name (Facebook, Twitter) an adversary can very easily de-anonymize and dox you. That can be especially damning for you if you appear on a platform anonymously and want it to stay that way (dating platforms, file sharing platforms, free speech platforms).
Data on the internet also has the tendency to be there for a long time, so this threat is very persistent.
1
Not to mention that just about any internet user is likely to have been caught up in one breach or another where a password has leaked. And since way too many users reuse passwords, if someone has one of your breached password and a list of sites you visit, it could be trivial for them to breach one of your sites.
– Shawn
10 hours ago
add a comment |
up vote
2
down vote
I'll try my hand at this one... Keep in mind that there is a difference between 'all possible' and 'targeted attacks'. With that in mind, I'd break up the attack types into at least two categories: cyber and behavioral. They can be derived from one another but are inherently different in nature.
Cyber threats to someone having access to your URLs:
HTTP POST/GET Variables -- If a particular website practices poor security standards like including sensitive personally identifiable information or secrets (passwords) in reversible or plaintext methods, this is probably the most apparent--but as I said in @schroeder's answer comments, you'd have to evaluate each URL as https://someco.com/sub1/?var1=something;var2=somethingelse might be securely written but http://someco.com/sub2/var1=something;var2=secrets. This is because most large web presences have a small army of web developers working on their front-end, back-end, and everything in between. Where there is a lack of standards in each org (which is never known to us, end-users) one part of a page may be worse off than others.
While session data also has interesting information, it cannot be gleaned from URLs alone. So while interesting from a host-compromise scenario, it's not applicable here which is why I asked for scope of the question in my original comment.
Cyber+Behavioral threats to someone having access to your URLs
Personal Weaknesses: What sites you frequent indicates social patterns: likes/dislikes, politics, health, wealth, etc. e.g.: If an attacker is targeting you for exploitation and knows you're visiting debt consolidation sites, they might offer you financial help in return for favors. If you're frequenting ashleymadison.com and you're married, they might approach you with blackmail to not out you to your spouse. I don't mean this to be offensive but assuming you're un-blackmailable is rather naive.
Personal Habits: If you're a creature of habit (as most people are), over time, they can see the times of the day you're connected to the Internet and potentially from what device(s) and what location(s). If the attacker is targeting your house, they can derive when you work, when you're home, and how erratic a confidence-level is in predicting where you'll be tomorrow or the next day.
add a comment |
up vote
0
down vote
To add to the post about information leakage in URL:
An attacker that has this may:
1: Extract what sites you use to try and log into to see if you are using the same creds [assumes attacker has captured a cred]
2: This info grants much more advanced knowledge for creating phishing attacks EX: "you've been selected to screen the new MLP season [whatever]"
3: Possible physical tracking based on sites "oh their kid goes to "little gals daycare" because I see them log into to pay that bill"
Could be more depending on what's in there.
I'm not sure how the URL parameters provide all that. Just the URLs would be enough.
– schroeder♦
yesterday
1
@schroeder I didn't see that the question asked for only information that would need parameters.
– Acccumulation
yesterday
@Acccumulation the focus is on the parameters, yes
– schroeder♦
yesterday
1
@schroeder parameters are mentioned but the question is: "What attacks are made possible by public release of my web history?" Please make sure to clearly check the question. Thank you.
– bashCypher
yesterday
@bashCypher The OP discounts the sites themselves (domains), and explicitly states is concerned about "secure information might be passed in a URL somewhere" and " leakage of information via the URL itself". And the example is clearly about the large number of parameters.
– schroeder♦
23 hours ago
|
show 1 more comment
up vote
0
down vote
Having your browsing history exposed means the attacker has in possession the list of url's your browser has accessed. From a complex url an attacker can identify these information:
- Protocol
- Subdomain
- Domain
- Port
- Path
- Parameters of a query
- Fragment
Now, your privacy depends on the way the developer has built the site.
If you logged in in a website that has an url like this:
www.example.com/?login=**myusers**&password=**mypassword**
then the attacker has your credentials for that site.
Some of possible attacks would be:
- sql injection
- URL Manipulation
- Directory Traversal
- Identify theft
In simple words, your privacy/risk depends on the security level the site has.
5
All of the attacks you list are attacks that could be possible against sites that he visited, none of them are attacks against him made possible by disclosure of the urls. URL Manipulation could be relevant, but I don't see how sql injection or directory traversal are.
– AndrolGenhald
yesterday
Bad security of a site, brings automatically a threat to the users whom have information stored on that site.
– Vini7
yesterday
6
Absolutely, but that threat exists with or without OP's browser history being exposed. The browser history may allow someone targeting him to look for vulnerabilities in those specific sites because they know he has an account there, but I certainly wouldn't say "sql injection is made possible by public release of browser history".
– AndrolGenhald
yesterday
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Joe is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f199557%2fwhat-attacks-are-made-possible-by-public-release-of-my-web-history%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
42
down vote
accepted
Your question might be more undefined than you realise. Any kind of data can be passed using URL parameters. Usernames, passwords, authentication tokens, settings, form data, or anything the web developer chooses. It's not always good practice to use URL parameters to for this, but it is always possible.
And it's entirely up to each individual web developer on each individual page (not just site) as to what might be exposed and when. So you might not be able to predict what might be exposed.
So, to answer your question, in the worst case, you could experience a complete and utter disclosure of any amount of personal data including credentials.
By request, I did a search for the practice of "passwords in URL parameters" and restricted results to this year. Here's one of the top hits:
https://answers.splunk.com/answers/622600/how-to-pass-username-and-password-as-a-parameter-v.html
That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this.
Here is OWASP's official page on this vulnerability:
The parameter values for 'user', 'authz_token', and 'expire' will be
exposed in the following locations when using HTTP or HTTPS:
Referer
Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing
4
The only thing I'd add to this is that the problem is also worse because while you're correct that any data can be passed via URL, the problem is compounded by the fact that what information is passed via a URL and whether and how it is secured is up to each individual company you're visiting and furthermore, the standards of the web programmers who developed each page. So you could never say by looking at one URL that there wasn't any sensitive data passed--you couldn't even say that about different URLs from the same site...
– thepip3r
yesterday
3
and even if passwords aren't passed in the query string, if the session token is, you'd better hope that the developers restricted it to a single IP address and limited time validity...
– Ben Voigt
yesterday
1
"That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this." That's misleading—your link is to a community forum, where two Splunk users are discussing doing this unsafely. It's not a demonstration of Splunk itself passing sensitive information in URL parameters.
– Justin Lardinois
11 hours ago
1
@JustinLardinois not misleading at all - Splunk actually offers the settingenable_insecure_login
Splunk is actually passing sensitive information
– schroeder♦
10 hours ago
1
@schroeder From that answer, though, it looks like it's something that's disabled by default.
– Justin Lardinois
5 hours ago
|
show 2 more comments
up vote
42
down vote
accepted
Your question might be more undefined than you realise. Any kind of data can be passed using URL parameters. Usernames, passwords, authentication tokens, settings, form data, or anything the web developer chooses. It's not always good practice to use URL parameters to for this, but it is always possible.
And it's entirely up to each individual web developer on each individual page (not just site) as to what might be exposed and when. So you might not be able to predict what might be exposed.
So, to answer your question, in the worst case, you could experience a complete and utter disclosure of any amount of personal data including credentials.
By request, I did a search for the practice of "passwords in URL parameters" and restricted results to this year. Here's one of the top hits:
https://answers.splunk.com/answers/622600/how-to-pass-username-and-password-as-a-parameter-v.html
That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this.
Here is OWASP's official page on this vulnerability:
The parameter values for 'user', 'authz_token', and 'expire' will be
exposed in the following locations when using HTTP or HTTPS:
Referer
Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing
4
The only thing I'd add to this is that the problem is also worse because while you're correct that any data can be passed via URL, the problem is compounded by the fact that what information is passed via a URL and whether and how it is secured is up to each individual company you're visiting and furthermore, the standards of the web programmers who developed each page. So you could never say by looking at one URL that there wasn't any sensitive data passed--you couldn't even say that about different URLs from the same site...
– thepip3r
yesterday
3
and even if passwords aren't passed in the query string, if the session token is, you'd better hope that the developers restricted it to a single IP address and limited time validity...
– Ben Voigt
yesterday
1
"That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this." That's misleading—your link is to a community forum, where two Splunk users are discussing doing this unsafely. It's not a demonstration of Splunk itself passing sensitive information in URL parameters.
– Justin Lardinois
11 hours ago
1
@JustinLardinois not misleading at all - Splunk actually offers the settingenable_insecure_login
Splunk is actually passing sensitive information
– schroeder♦
10 hours ago
1
@schroeder From that answer, though, it looks like it's something that's disabled by default.
– Justin Lardinois
5 hours ago
|
show 2 more comments
up vote
42
down vote
accepted
up vote
42
down vote
accepted
Your question might be more undefined than you realise. Any kind of data can be passed using URL parameters. Usernames, passwords, authentication tokens, settings, form data, or anything the web developer chooses. It's not always good practice to use URL parameters to for this, but it is always possible.
And it's entirely up to each individual web developer on each individual page (not just site) as to what might be exposed and when. So you might not be able to predict what might be exposed.
So, to answer your question, in the worst case, you could experience a complete and utter disclosure of any amount of personal data including credentials.
By request, I did a search for the practice of "passwords in URL parameters" and restricted results to this year. Here's one of the top hits:
https://answers.splunk.com/answers/622600/how-to-pass-username-and-password-as-a-parameter-v.html
That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this.
Here is OWASP's official page on this vulnerability:
The parameter values for 'user', 'authz_token', and 'expire' will be
exposed in the following locations when using HTTP or HTTPS:
Referer
Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing
Your question might be more undefined than you realise. Any kind of data can be passed using URL parameters. Usernames, passwords, authentication tokens, settings, form data, or anything the web developer chooses. It's not always good practice to use URL parameters to for this, but it is always possible.
And it's entirely up to each individual web developer on each individual page (not just site) as to what might be exposed and when. So you might not be able to predict what might be exposed.
So, to answer your question, in the worst case, you could experience a complete and utter disclosure of any amount of personal data including credentials.
By request, I did a search for the practice of "passwords in URL parameters" and restricted results to this year. Here's one of the top hits:
https://answers.splunk.com/answers/622600/how-to-pass-username-and-password-as-a-parameter-v.html
That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this.
Here is OWASP's official page on this vulnerability:
The parameter values for 'user', 'authz_token', and 'expire' will be
exposed in the following locations when using HTTP or HTTPS:
Referer
Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing
edited yesterday
answered yesterday
schroeder♦
72.5k29160194
72.5k29160194
4
The only thing I'd add to this is that the problem is also worse because while you're correct that any data can be passed via URL, the problem is compounded by the fact that what information is passed via a URL and whether and how it is secured is up to each individual company you're visiting and furthermore, the standards of the web programmers who developed each page. So you could never say by looking at one URL that there wasn't any sensitive data passed--you couldn't even say that about different URLs from the same site...
– thepip3r
yesterday
3
and even if passwords aren't passed in the query string, if the session token is, you'd better hope that the developers restricted it to a single IP address and limited time validity...
– Ben Voigt
yesterday
1
"That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this." That's misleading—your link is to a community forum, where two Splunk users are discussing doing this unsafely. It's not a demonstration of Splunk itself passing sensitive information in URL parameters.
– Justin Lardinois
11 hours ago
1
@JustinLardinois not misleading at all - Splunk actually offers the settingenable_insecure_login
Splunk is actually passing sensitive information
– schroeder♦
10 hours ago
1
@schroeder From that answer, though, it looks like it's something that's disabled by default.
– Justin Lardinois
5 hours ago
|
show 2 more comments
4
The only thing I'd add to this is that the problem is also worse because while you're correct that any data can be passed via URL, the problem is compounded by the fact that what information is passed via a URL and whether and how it is secured is up to each individual company you're visiting and furthermore, the standards of the web programmers who developed each page. So you could never say by looking at one URL that there wasn't any sensitive data passed--you couldn't even say that about different URLs from the same site...
– thepip3r
yesterday
3
and even if passwords aren't passed in the query string, if the session token is, you'd better hope that the developers restricted it to a single IP address and limited time validity...
– Ben Voigt
yesterday
1
"That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this." That's misleading—your link is to a community forum, where two Splunk users are discussing doing this unsafely. It's not a demonstration of Splunk itself passing sensitive information in URL parameters.
– Justin Lardinois
11 hours ago
1
@JustinLardinois not misleading at all - Splunk actually offers the settingenable_insecure_login
Splunk is actually passing sensitive information
– schroeder♦
10 hours ago
1
@schroeder From that answer, though, it looks like it's something that's disabled by default.
– Justin Lardinois
5 hours ago
4
4
The only thing I'd add to this is that the problem is also worse because while you're correct that any data can be passed via URL, the problem is compounded by the fact that what information is passed via a URL and whether and how it is secured is up to each individual company you're visiting and furthermore, the standards of the web programmers who developed each page. So you could never say by looking at one URL that there wasn't any sensitive data passed--you couldn't even say that about different URLs from the same site...
– thepip3r
yesterday
The only thing I'd add to this is that the problem is also worse because while you're correct that any data can be passed via URL, the problem is compounded by the fact that what information is passed via a URL and whether and how it is secured is up to each individual company you're visiting and furthermore, the standards of the web programmers who developed each page. So you could never say by looking at one URL that there wasn't any sensitive data passed--you couldn't even say that about different URLs from the same site...
– thepip3r
yesterday
3
3
and even if passwords aren't passed in the query string, if the session token is, you'd better hope that the developers restricted it to a single IP address and limited time validity...
– Ben Voigt
yesterday
and even if passwords aren't passed in the query string, if the session token is, you'd better hope that the developers restricted it to a single IP address and limited time validity...
– Ben Voigt
yesterday
1
1
"That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this." That's misleading—your link is to a community forum, where two Splunk users are discussing doing this unsafely. It's not a demonstration of Splunk itself passing sensitive information in URL parameters.
– Justin Lardinois
11 hours ago
"That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this." That's misleading—your link is to a community forum, where two Splunk users are discussing doing this unsafely. It's not a demonstration of Splunk itself passing sensitive information in URL parameters.
– Justin Lardinois
11 hours ago
1
1
@JustinLardinois not misleading at all - Splunk actually offers the setting
enable_insecure_login
Splunk is actually passing sensitive information– schroeder♦
10 hours ago
@JustinLardinois not misleading at all - Splunk actually offers the setting
enable_insecure_login
Splunk is actually passing sensitive information– schroeder♦
10 hours ago
1
1
@schroeder From that answer, though, it looks like it's something that's disabled by default.
– Justin Lardinois
5 hours ago
@schroeder From that answer, though, it looks like it's something that's disabled by default.
– Justin Lardinois
5 hours ago
|
show 2 more comments
up vote
12
down vote
Quite a bit actually:
- Extortion based off content
- Mapping systems that are not public
- Sensitive parameters in certain requests
- Personal information
Extortion
That search of yours that may be embarrassing and taken out of context. A WebMD search for a medical condition you don't want made known to co-workers for example. A search that was best done in incognito mode you forgot about.
Mapping systems that are not public
How about your works intranet site or that production web portal, well those names are going to pop up in your history now and if its something like Jenkins - thats a great candidate for a DNS rebind attack.
Sensitive parameters in certain requests
If you visit a site that just does the internet wrong and the parameter contains an API key, password, credential or just an account ID well that is captured and can be used now.
Personal information
I see you've been searching for holidays in March for 2 weeks - that would be a great time to break in to your house or impersonate you. Looking for an engagement ring well that sounds like something worth stealing. You did a google map from your address to another location?
add a comment |
up vote
12
down vote
Quite a bit actually:
- Extortion based off content
- Mapping systems that are not public
- Sensitive parameters in certain requests
- Personal information
Extortion
That search of yours that may be embarrassing and taken out of context. A WebMD search for a medical condition you don't want made known to co-workers for example. A search that was best done in incognito mode you forgot about.
Mapping systems that are not public
How about your works intranet site or that production web portal, well those names are going to pop up in your history now and if its something like Jenkins - thats a great candidate for a DNS rebind attack.
Sensitive parameters in certain requests
If you visit a site that just does the internet wrong and the parameter contains an API key, password, credential or just an account ID well that is captured and can be used now.
Personal information
I see you've been searching for holidays in March for 2 weeks - that would be a great time to break in to your house or impersonate you. Looking for an engagement ring well that sounds like something worth stealing. You did a google map from your address to another location?
add a comment |
up vote
12
down vote
up vote
12
down vote
Quite a bit actually:
- Extortion based off content
- Mapping systems that are not public
- Sensitive parameters in certain requests
- Personal information
Extortion
That search of yours that may be embarrassing and taken out of context. A WebMD search for a medical condition you don't want made known to co-workers for example. A search that was best done in incognito mode you forgot about.
Mapping systems that are not public
How about your works intranet site or that production web portal, well those names are going to pop up in your history now and if its something like Jenkins - thats a great candidate for a DNS rebind attack.
Sensitive parameters in certain requests
If you visit a site that just does the internet wrong and the parameter contains an API key, password, credential or just an account ID well that is captured and can be used now.
Personal information
I see you've been searching for holidays in March for 2 weeks - that would be a great time to break in to your house or impersonate you. Looking for an engagement ring well that sounds like something worth stealing. You did a google map from your address to another location?
Quite a bit actually:
- Extortion based off content
- Mapping systems that are not public
- Sensitive parameters in certain requests
- Personal information
Extortion
That search of yours that may be embarrassing and taken out of context. A WebMD search for a medical condition you don't want made known to co-workers for example. A search that was best done in incognito mode you forgot about.
Mapping systems that are not public
How about your works intranet site or that production web portal, well those names are going to pop up in your history now and if its something like Jenkins - thats a great candidate for a DNS rebind attack.
Sensitive parameters in certain requests
If you visit a site that just does the internet wrong and the parameter contains an API key, password, credential or just an account ID well that is captured and can be used now.
Personal information
I see you've been searching for holidays in March for 2 weeks - that would be a great time to break in to your house or impersonate you. Looking for an engagement ring well that sounds like something worth stealing. You did a google map from your address to another location?
answered yesterday
McMatty
2,6201214
2,6201214
add a comment |
add a comment |
up vote
7
down vote
One of the threats I'd like to mention that has not been named yet is de-anonymization.
The URIs in your history could leak information about your user accounts on different sites - for instance if you constantly check your own profile on social media sites. If you use some web services anonymously and others under your real name (Facebook, Twitter) an adversary can very easily de-anonymize and dox you. That can be especially damning for you if you appear on a platform anonymously and want it to stay that way (dating platforms, file sharing platforms, free speech platforms).
Data on the internet also has the tendency to be there for a long time, so this threat is very persistent.
1
Not to mention that just about any internet user is likely to have been caught up in one breach or another where a password has leaked. And since way too many users reuse passwords, if someone has one of your breached password and a list of sites you visit, it could be trivial for them to breach one of your sites.
– Shawn
10 hours ago
add a comment |
up vote
7
down vote
One of the threats I'd like to mention that has not been named yet is de-anonymization.
The URIs in your history could leak information about your user accounts on different sites - for instance if you constantly check your own profile on social media sites. If you use some web services anonymously and others under your real name (Facebook, Twitter) an adversary can very easily de-anonymize and dox you. That can be especially damning for you if you appear on a platform anonymously and want it to stay that way (dating platforms, file sharing platforms, free speech platforms).
Data on the internet also has the tendency to be there for a long time, so this threat is very persistent.
1
Not to mention that just about any internet user is likely to have been caught up in one breach or another where a password has leaked. And since way too many users reuse passwords, if someone has one of your breached password and a list of sites you visit, it could be trivial for them to breach one of your sites.
– Shawn
10 hours ago
add a comment |
up vote
7
down vote
up vote
7
down vote
One of the threats I'd like to mention that has not been named yet is de-anonymization.
The URIs in your history could leak information about your user accounts on different sites - for instance if you constantly check your own profile on social media sites. If you use some web services anonymously and others under your real name (Facebook, Twitter) an adversary can very easily de-anonymize and dox you. That can be especially damning for you if you appear on a platform anonymously and want it to stay that way (dating platforms, file sharing platforms, free speech platforms).
Data on the internet also has the tendency to be there for a long time, so this threat is very persistent.
One of the threats I'd like to mention that has not been named yet is de-anonymization.
The URIs in your history could leak information about your user accounts on different sites - for instance if you constantly check your own profile on social media sites. If you use some web services anonymously and others under your real name (Facebook, Twitter) an adversary can very easily de-anonymize and dox you. That can be especially damning for you if you appear on a platform anonymously and want it to stay that way (dating platforms, file sharing platforms, free speech platforms).
Data on the internet also has the tendency to be there for a long time, so this threat is very persistent.
answered yesterday
Tom K.
5,28032047
5,28032047
1
Not to mention that just about any internet user is likely to have been caught up in one breach or another where a password has leaked. And since way too many users reuse passwords, if someone has one of your breached password and a list of sites you visit, it could be trivial for them to breach one of your sites.
– Shawn
10 hours ago
add a comment |
1
Not to mention that just about any internet user is likely to have been caught up in one breach or another where a password has leaked. And since way too many users reuse passwords, if someone has one of your breached password and a list of sites you visit, it could be trivial for them to breach one of your sites.
– Shawn
10 hours ago
1
1
Not to mention that just about any internet user is likely to have been caught up in one breach or another where a password has leaked. And since way too many users reuse passwords, if someone has one of your breached password and a list of sites you visit, it could be trivial for them to breach one of your sites.
– Shawn
10 hours ago
Not to mention that just about any internet user is likely to have been caught up in one breach or another where a password has leaked. And since way too many users reuse passwords, if someone has one of your breached password and a list of sites you visit, it could be trivial for them to breach one of your sites.
– Shawn
10 hours ago
add a comment |
up vote
2
down vote
I'll try my hand at this one... Keep in mind that there is a difference between 'all possible' and 'targeted attacks'. With that in mind, I'd break up the attack types into at least two categories: cyber and behavioral. They can be derived from one another but are inherently different in nature.
Cyber threats to someone having access to your URLs:
HTTP POST/GET Variables -- If a particular website practices poor security standards like including sensitive personally identifiable information or secrets (passwords) in reversible or plaintext methods, this is probably the most apparent--but as I said in @schroeder's answer comments, you'd have to evaluate each URL as https://someco.com/sub1/?var1=something;var2=somethingelse might be securely written but http://someco.com/sub2/var1=something;var2=secrets. This is because most large web presences have a small army of web developers working on their front-end, back-end, and everything in between. Where there is a lack of standards in each org (which is never known to us, end-users) one part of a page may be worse off than others.
While session data also has interesting information, it cannot be gleaned from URLs alone. So while interesting from a host-compromise scenario, it's not applicable here which is why I asked for scope of the question in my original comment.
Cyber+Behavioral threats to someone having access to your URLs
Personal Weaknesses: What sites you frequent indicates social patterns: likes/dislikes, politics, health, wealth, etc. e.g.: If an attacker is targeting you for exploitation and knows you're visiting debt consolidation sites, they might offer you financial help in return for favors. If you're frequenting ashleymadison.com and you're married, they might approach you with blackmail to not out you to your spouse. I don't mean this to be offensive but assuming you're un-blackmailable is rather naive.
Personal Habits: If you're a creature of habit (as most people are), over time, they can see the times of the day you're connected to the Internet and potentially from what device(s) and what location(s). If the attacker is targeting your house, they can derive when you work, when you're home, and how erratic a confidence-level is in predicting where you'll be tomorrow or the next day.
add a comment |
up vote
2
down vote
I'll try my hand at this one... Keep in mind that there is a difference between 'all possible' and 'targeted attacks'. With that in mind, I'd break up the attack types into at least two categories: cyber and behavioral. They can be derived from one another but are inherently different in nature.
Cyber threats to someone having access to your URLs:
HTTP POST/GET Variables -- If a particular website practices poor security standards like including sensitive personally identifiable information or secrets (passwords) in reversible or plaintext methods, this is probably the most apparent--but as I said in @schroeder's answer comments, you'd have to evaluate each URL as https://someco.com/sub1/?var1=something;var2=somethingelse might be securely written but http://someco.com/sub2/var1=something;var2=secrets. This is because most large web presences have a small army of web developers working on their front-end, back-end, and everything in between. Where there is a lack of standards in each org (which is never known to us, end-users) one part of a page may be worse off than others.
While session data also has interesting information, it cannot be gleaned from URLs alone. So while interesting from a host-compromise scenario, it's not applicable here which is why I asked for scope of the question in my original comment.
Cyber+Behavioral threats to someone having access to your URLs
Personal Weaknesses: What sites you frequent indicates social patterns: likes/dislikes, politics, health, wealth, etc. e.g.: If an attacker is targeting you for exploitation and knows you're visiting debt consolidation sites, they might offer you financial help in return for favors. If you're frequenting ashleymadison.com and you're married, they might approach you with blackmail to not out you to your spouse. I don't mean this to be offensive but assuming you're un-blackmailable is rather naive.
Personal Habits: If you're a creature of habit (as most people are), over time, they can see the times of the day you're connected to the Internet and potentially from what device(s) and what location(s). If the attacker is targeting your house, they can derive when you work, when you're home, and how erratic a confidence-level is in predicting where you'll be tomorrow or the next day.
add a comment |
up vote
2
down vote
up vote
2
down vote
I'll try my hand at this one... Keep in mind that there is a difference between 'all possible' and 'targeted attacks'. With that in mind, I'd break up the attack types into at least two categories: cyber and behavioral. They can be derived from one another but are inherently different in nature.
Cyber threats to someone having access to your URLs:
HTTP POST/GET Variables -- If a particular website practices poor security standards like including sensitive personally identifiable information or secrets (passwords) in reversible or plaintext methods, this is probably the most apparent--but as I said in @schroeder's answer comments, you'd have to evaluate each URL as https://someco.com/sub1/?var1=something;var2=somethingelse might be securely written but http://someco.com/sub2/var1=something;var2=secrets. This is because most large web presences have a small army of web developers working on their front-end, back-end, and everything in between. Where there is a lack of standards in each org (which is never known to us, end-users) one part of a page may be worse off than others.
While session data also has interesting information, it cannot be gleaned from URLs alone. So while interesting from a host-compromise scenario, it's not applicable here which is why I asked for scope of the question in my original comment.
Cyber+Behavioral threats to someone having access to your URLs
Personal Weaknesses: What sites you frequent indicates social patterns: likes/dislikes, politics, health, wealth, etc. e.g.: If an attacker is targeting you for exploitation and knows you're visiting debt consolidation sites, they might offer you financial help in return for favors. If you're frequenting ashleymadison.com and you're married, they might approach you with blackmail to not out you to your spouse. I don't mean this to be offensive but assuming you're un-blackmailable is rather naive.
Personal Habits: If you're a creature of habit (as most people are), over time, they can see the times of the day you're connected to the Internet and potentially from what device(s) and what location(s). If the attacker is targeting your house, they can derive when you work, when you're home, and how erratic a confidence-level is in predicting where you'll be tomorrow or the next day.
I'll try my hand at this one... Keep in mind that there is a difference between 'all possible' and 'targeted attacks'. With that in mind, I'd break up the attack types into at least two categories: cyber and behavioral. They can be derived from one another but are inherently different in nature.
Cyber threats to someone having access to your URLs:
HTTP POST/GET Variables -- If a particular website practices poor security standards like including sensitive personally identifiable information or secrets (passwords) in reversible or plaintext methods, this is probably the most apparent--but as I said in @schroeder's answer comments, you'd have to evaluate each URL as https://someco.com/sub1/?var1=something;var2=somethingelse might be securely written but http://someco.com/sub2/var1=something;var2=secrets. This is because most large web presences have a small army of web developers working on their front-end, back-end, and everything in between. Where there is a lack of standards in each org (which is never known to us, end-users) one part of a page may be worse off than others.
While session data also has interesting information, it cannot be gleaned from URLs alone. So while interesting from a host-compromise scenario, it's not applicable here which is why I asked for scope of the question in my original comment.
Cyber+Behavioral threats to someone having access to your URLs
Personal Weaknesses: What sites you frequent indicates social patterns: likes/dislikes, politics, health, wealth, etc. e.g.: If an attacker is targeting you for exploitation and knows you're visiting debt consolidation sites, they might offer you financial help in return for favors. If you're frequenting ashleymadison.com and you're married, they might approach you with blackmail to not out you to your spouse. I don't mean this to be offensive but assuming you're un-blackmailable is rather naive.
Personal Habits: If you're a creature of habit (as most people are), over time, they can see the times of the day you're connected to the Internet and potentially from what device(s) and what location(s). If the attacker is targeting your house, they can derive when you work, when you're home, and how erratic a confidence-level is in predicting where you'll be tomorrow or the next day.
answered 14 hours ago
thepip3r
36718
36718
add a comment |
add a comment |
up vote
0
down vote
To add to the post about information leakage in URL:
An attacker that has this may:
1: Extract what sites you use to try and log into to see if you are using the same creds [assumes attacker has captured a cred]
2: This info grants much more advanced knowledge for creating phishing attacks EX: "you've been selected to screen the new MLP season [whatever]"
3: Possible physical tracking based on sites "oh their kid goes to "little gals daycare" because I see them log into to pay that bill"
Could be more depending on what's in there.
I'm not sure how the URL parameters provide all that. Just the URLs would be enough.
– schroeder♦
yesterday
1
@schroeder I didn't see that the question asked for only information that would need parameters.
– Acccumulation
yesterday
@Acccumulation the focus is on the parameters, yes
– schroeder♦
yesterday
1
@schroeder parameters are mentioned but the question is: "What attacks are made possible by public release of my web history?" Please make sure to clearly check the question. Thank you.
– bashCypher
yesterday
@bashCypher The OP discounts the sites themselves (domains), and explicitly states is concerned about "secure information might be passed in a URL somewhere" and " leakage of information via the URL itself". And the example is clearly about the large number of parameters.
– schroeder♦
23 hours ago
|
show 1 more comment
up vote
0
down vote
To add to the post about information leakage in URL:
An attacker that has this may:
1: Extract what sites you use to try and log into to see if you are using the same creds [assumes attacker has captured a cred]
2: This info grants much more advanced knowledge for creating phishing attacks EX: "you've been selected to screen the new MLP season [whatever]"
3: Possible physical tracking based on sites "oh their kid goes to "little gals daycare" because I see them log into to pay that bill"
Could be more depending on what's in there.
I'm not sure how the URL parameters provide all that. Just the URLs would be enough.
– schroeder♦
yesterday
1
@schroeder I didn't see that the question asked for only information that would need parameters.
– Acccumulation
yesterday
@Acccumulation the focus is on the parameters, yes
– schroeder♦
yesterday
1
@schroeder parameters are mentioned but the question is: "What attacks are made possible by public release of my web history?" Please make sure to clearly check the question. Thank you.
– bashCypher
yesterday
@bashCypher The OP discounts the sites themselves (domains), and explicitly states is concerned about "secure information might be passed in a URL somewhere" and " leakage of information via the URL itself". And the example is clearly about the large number of parameters.
– schroeder♦
23 hours ago
|
show 1 more comment
up vote
0
down vote
up vote
0
down vote
To add to the post about information leakage in URL:
An attacker that has this may:
1: Extract what sites you use to try and log into to see if you are using the same creds [assumes attacker has captured a cred]
2: This info grants much more advanced knowledge for creating phishing attacks EX: "you've been selected to screen the new MLP season [whatever]"
3: Possible physical tracking based on sites "oh their kid goes to "little gals daycare" because I see them log into to pay that bill"
Could be more depending on what's in there.
To add to the post about information leakage in URL:
An attacker that has this may:
1: Extract what sites you use to try and log into to see if you are using the same creds [assumes attacker has captured a cred]
2: This info grants much more advanced knowledge for creating phishing attacks EX: "you've been selected to screen the new MLP season [whatever]"
3: Possible physical tracking based on sites "oh their kid goes to "little gals daycare" because I see them log into to pay that bill"
Could be more depending on what's in there.
edited yesterday
answered yesterday
bashCypher
680111
680111
I'm not sure how the URL parameters provide all that. Just the URLs would be enough.
– schroeder♦
yesterday
1
@schroeder I didn't see that the question asked for only information that would need parameters.
– Acccumulation
yesterday
@Acccumulation the focus is on the parameters, yes
– schroeder♦
yesterday
1
@schroeder parameters are mentioned but the question is: "What attacks are made possible by public release of my web history?" Please make sure to clearly check the question. Thank you.
– bashCypher
yesterday
@bashCypher The OP discounts the sites themselves (domains), and explicitly states is concerned about "secure information might be passed in a URL somewhere" and " leakage of information via the URL itself". And the example is clearly about the large number of parameters.
– schroeder♦
23 hours ago
|
show 1 more comment
I'm not sure how the URL parameters provide all that. Just the URLs would be enough.
– schroeder♦
yesterday
1
@schroeder I didn't see that the question asked for only information that would need parameters.
– Acccumulation
yesterday
@Acccumulation the focus is on the parameters, yes
– schroeder♦
yesterday
1
@schroeder parameters are mentioned but the question is: "What attacks are made possible by public release of my web history?" Please make sure to clearly check the question. Thank you.
– bashCypher
yesterday
@bashCypher The OP discounts the sites themselves (domains), and explicitly states is concerned about "secure information might be passed in a URL somewhere" and " leakage of information via the URL itself". And the example is clearly about the large number of parameters.
– schroeder♦
23 hours ago
I'm not sure how the URL parameters provide all that. Just the URLs would be enough.
– schroeder♦
yesterday
I'm not sure how the URL parameters provide all that. Just the URLs would be enough.
– schroeder♦
yesterday
1
1
@schroeder I didn't see that the question asked for only information that would need parameters.
– Acccumulation
yesterday
@schroeder I didn't see that the question asked for only information that would need parameters.
– Acccumulation
yesterday
@Acccumulation the focus is on the parameters, yes
– schroeder♦
yesterday
@Acccumulation the focus is on the parameters, yes
– schroeder♦
yesterday
1
1
@schroeder parameters are mentioned but the question is: "What attacks are made possible by public release of my web history?" Please make sure to clearly check the question. Thank you.
– bashCypher
yesterday
@schroeder parameters are mentioned but the question is: "What attacks are made possible by public release of my web history?" Please make sure to clearly check the question. Thank you.
– bashCypher
yesterday
@bashCypher The OP discounts the sites themselves (domains), and explicitly states is concerned about "secure information might be passed in a URL somewhere" and " leakage of information via the URL itself". And the example is clearly about the large number of parameters.
– schroeder♦
23 hours ago
@bashCypher The OP discounts the sites themselves (domains), and explicitly states is concerned about "secure information might be passed in a URL somewhere" and " leakage of information via the URL itself". And the example is clearly about the large number of parameters.
– schroeder♦
23 hours ago
|
show 1 more comment
up vote
0
down vote
Having your browsing history exposed means the attacker has in possession the list of url's your browser has accessed. From a complex url an attacker can identify these information:
- Protocol
- Subdomain
- Domain
- Port
- Path
- Parameters of a query
- Fragment
Now, your privacy depends on the way the developer has built the site.
If you logged in in a website that has an url like this:
www.example.com/?login=**myusers**&password=**mypassword**
then the attacker has your credentials for that site.
Some of possible attacks would be:
- sql injection
- URL Manipulation
- Directory Traversal
- Identify theft
In simple words, your privacy/risk depends on the security level the site has.
5
All of the attacks you list are attacks that could be possible against sites that he visited, none of them are attacks against him made possible by disclosure of the urls. URL Manipulation could be relevant, but I don't see how sql injection or directory traversal are.
– AndrolGenhald
yesterday
Bad security of a site, brings automatically a threat to the users whom have information stored on that site.
– Vini7
yesterday
6
Absolutely, but that threat exists with or without OP's browser history being exposed. The browser history may allow someone targeting him to look for vulnerabilities in those specific sites because they know he has an account there, but I certainly wouldn't say "sql injection is made possible by public release of browser history".
– AndrolGenhald
yesterday
add a comment |
up vote
0
down vote
Having your browsing history exposed means the attacker has in possession the list of url's your browser has accessed. From a complex url an attacker can identify these information:
- Protocol
- Subdomain
- Domain
- Port
- Path
- Parameters of a query
- Fragment
Now, your privacy depends on the way the developer has built the site.
If you logged in in a website that has an url like this:
www.example.com/?login=**myusers**&password=**mypassword**
then the attacker has your credentials for that site.
Some of possible attacks would be:
- sql injection
- URL Manipulation
- Directory Traversal
- Identify theft
In simple words, your privacy/risk depends on the security level the site has.
5
All of the attacks you list are attacks that could be possible against sites that he visited, none of them are attacks against him made possible by disclosure of the urls. URL Manipulation could be relevant, but I don't see how sql injection or directory traversal are.
– AndrolGenhald
yesterday
Bad security of a site, brings automatically a threat to the users whom have information stored on that site.
– Vini7
yesterday
6
Absolutely, but that threat exists with or without OP's browser history being exposed. The browser history may allow someone targeting him to look for vulnerabilities in those specific sites because they know he has an account there, but I certainly wouldn't say "sql injection is made possible by public release of browser history".
– AndrolGenhald
yesterday
add a comment |
up vote
0
down vote
up vote
0
down vote
Having your browsing history exposed means the attacker has in possession the list of url's your browser has accessed. From a complex url an attacker can identify these information:
- Protocol
- Subdomain
- Domain
- Port
- Path
- Parameters of a query
- Fragment
Now, your privacy depends on the way the developer has built the site.
If you logged in in a website that has an url like this:
www.example.com/?login=**myusers**&password=**mypassword**
then the attacker has your credentials for that site.
Some of possible attacks would be:
- sql injection
- URL Manipulation
- Directory Traversal
- Identify theft
In simple words, your privacy/risk depends on the security level the site has.
Having your browsing history exposed means the attacker has in possession the list of url's your browser has accessed. From a complex url an attacker can identify these information:
- Protocol
- Subdomain
- Domain
- Port
- Path
- Parameters of a query
- Fragment
Now, your privacy depends on the way the developer has built the site.
If you logged in in a website that has an url like this:
www.example.com/?login=**myusers**&password=**mypassword**
then the attacker has your credentials for that site.
Some of possible attacks would be:
- sql injection
- URL Manipulation
- Directory Traversal
- Identify theft
In simple words, your privacy/risk depends on the security level the site has.
edited yesterday
AndrolGenhald
8,98241831
8,98241831
answered yesterday
Vini7
559413
559413
5
All of the attacks you list are attacks that could be possible against sites that he visited, none of them are attacks against him made possible by disclosure of the urls. URL Manipulation could be relevant, but I don't see how sql injection or directory traversal are.
– AndrolGenhald
yesterday
Bad security of a site, brings automatically a threat to the users whom have information stored on that site.
– Vini7
yesterday
6
Absolutely, but that threat exists with or without OP's browser history being exposed. The browser history may allow someone targeting him to look for vulnerabilities in those specific sites because they know he has an account there, but I certainly wouldn't say "sql injection is made possible by public release of browser history".
– AndrolGenhald
yesterday
add a comment |
5
All of the attacks you list are attacks that could be possible against sites that he visited, none of them are attacks against him made possible by disclosure of the urls. URL Manipulation could be relevant, but I don't see how sql injection or directory traversal are.
– AndrolGenhald
yesterday
Bad security of a site, brings automatically a threat to the users whom have information stored on that site.
– Vini7
yesterday
6
Absolutely, but that threat exists with or without OP's browser history being exposed. The browser history may allow someone targeting him to look for vulnerabilities in those specific sites because they know he has an account there, but I certainly wouldn't say "sql injection is made possible by public release of browser history".
– AndrolGenhald
yesterday
5
5
All of the attacks you list are attacks that could be possible against sites that he visited, none of them are attacks against him made possible by disclosure of the urls. URL Manipulation could be relevant, but I don't see how sql injection or directory traversal are.
– AndrolGenhald
yesterday
All of the attacks you list are attacks that could be possible against sites that he visited, none of them are attacks against him made possible by disclosure of the urls. URL Manipulation could be relevant, but I don't see how sql injection or directory traversal are.
– AndrolGenhald
yesterday
Bad security of a site, brings automatically a threat to the users whom have information stored on that site.
– Vini7
yesterday
Bad security of a site, brings automatically a threat to the users whom have information stored on that site.
– Vini7
yesterday
6
6
Absolutely, but that threat exists with or without OP's browser history being exposed. The browser history may allow someone targeting him to look for vulnerabilities in those specific sites because they know he has an account there, but I certainly wouldn't say "sql injection is made possible by public release of browser history".
– AndrolGenhald
yesterday
Absolutely, but that threat exists with or without OP's browser history being exposed. The browser history may allow someone targeting him to look for vulnerabilities in those specific sites because they know he has an account there, but I certainly wouldn't say "sql injection is made possible by public release of browser history".
– AndrolGenhald
yesterday
add a comment |
Joe is a new contributor. Be nice, and check out our Code of Conduct.
Joe is a new contributor. Be nice, and check out our Code of Conduct.
Joe is a new contributor. Be nice, and check out our Code of Conduct.
Joe is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f199557%2fwhat-attacks-are-made-possible-by-public-release-of-my-web-history%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Is it just your browser history or it a complete account/host compromise? It matters because, while your browser history might not provide much (unless you're into obscure porn), if they had access to your computer/profile, cookies, key loggers, screen scrapers are a whole different ballgame.
– thepip3r
yesterday
2
@thepip3r browser history only - and actually in this use case: url and timestamp pairs.
– Joe
yesterday
3
I can't believe that nobody mentioned spearphishing yet. With recent information of what you look at an attacker could easily send fake invoices or otherwise create very undetectable phishing mails.
– BlueWizard
10 hours ago