A small tool to view real-world ActivityPub objects as JSON! Enter a URL
or username from Mastodon or a similar service below, and we'll send a
request with
the right
Accept
header
to the server to view the underlying object.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"ostatus": "http://ostatus.org#",
"atomUri": "ostatus:atomUri",
"inReplyToAtomUri": "ostatus:inReplyToAtomUri",
"conversation": "ostatus:conversation",
"sensitive": "as:sensitive",
"toot": "http://joinmastodon.org/ns#",
"votersCount": "toot:votersCount",
"litepub": "http://litepub.social/ns#",
"directMessage": "litepub:directMessage"
}
],
"id": "https://infosec.exchange/users/saraislet/statuses/109431422536210250/replies",
"type": "Collection",
"first": {
"id": "https://infosec.exchange/users/saraislet/statuses/109431422536210250/replies?page=true",
"type": "CollectionPage",
"next": "https://infosec.exchange/users/saraislet/statuses/109431422536210250/replies?only_other_accounts=true&page=true",
"partOf": "https://infosec.exchange/users/saraislet/statuses/109431422536210250/replies",
"items": [
{
"id": "https://infosec.exchange/users/saraislet/statuses/109431836960949104",
"type": "Note",
"summary": null,
"inReplyTo": "https://infosec.exchange/users/saraislet/statuses/109431422536210250",
"published": "2022-11-30T08:35:16Z",
"url": "https://infosec.exchange/@saraislet/109431836960949104",
"attributedTo": "https://infosec.exchange/users/saraislet",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://infosec.exchange/users/saraislet/followers"
],
"sensitive": false,
"atomUri": "https://infosec.exchange/users/saraislet/statuses/109431836960949104",
"inReplyToAtomUri": "https://infosec.exchange/users/saraislet/statuses/109431422536210250",
"conversation": "tag:infosec.exchange,2022-11-29:objectId=25209978:objectType=Conversation",
"content": "<p>Let's get specific about WHY performance, caching, reliability, and latency are relevant to CDN security.</p><p>Indirectly, these properties are essential for engineering and business success. Another indirect benefit of valuing these properties as a security professional is the improved relationships you will have with engineering and product teams by showing your awareness and commitment to supporting shared goals. That pays dividends in spades.</p><p>What's *directly* relevant to securing a CDN?</p><p>1a. Performance: Security choices have performance consequences, so make it a good return on investment. CPU, memory, disk space, and even bandwidth come at a premium when we're talking about bare metal (and of course, if it isn't your bare metal, it's someone else's bare metal). Bare metal can't be scaled on demand to a cluster of m6idn.32xlarge instances — no matter how much money you offer the bear.</p><p>You have options when it comes to security controls, and you should have layers. CDN design often means you can shift those choices around — e.g., enforcing content authenticity verification at the client while removing or reducing the scope of File Integrity Monitoring on the server.</p><p>1b. Caching Problems: What happens if there's a time when you really *really* need that cached file or value to expire, and...it doesn't? Can you imagine situations where you *urgently* want a piece of content to be unavailable to anyone or anything that might request it? Let your imagination run wild: stolen keys or certificates, malicious JavaScript, installation bundles with vulnerable packages, inappropriate images... Maybe including this in security wasn't a bizarre idea after all, eh?</p><p>1c. Reliability: The obvious one.</p><p>1d. I...don't recall what I was thinking here. There's some fluid tradeoffs around elasticity, capacity, steering, client switchaway, load balancing, failover, and disaster recovery, so it all blends together.</p><p>Disaster recovery is a common security and reliability paradigm — but let's address that aspect later, along with data security.</p><p>Think in terms of what can go wrong on a CDN. Could an attacker intentionally trigger client switchaway, or bad choices around steering or load balancing? Maybe to a spoofed or compromised server controlled by an attacker?</p>",
"contentMap": {
"en": "<p>Let's get specific about WHY performance, caching, reliability, and latency are relevant to CDN security.</p><p>Indirectly, these properties are essential for engineering and business success. Another indirect benefit of valuing these properties as a security professional is the improved relationships you will have with engineering and product teams by showing your awareness and commitment to supporting shared goals. That pays dividends in spades.</p><p>What's *directly* relevant to securing a CDN?</p><p>1a. Performance: Security choices have performance consequences, so make it a good return on investment. CPU, memory, disk space, and even bandwidth come at a premium when we're talking about bare metal (and of course, if it isn't your bare metal, it's someone else's bare metal). Bare metal can't be scaled on demand to a cluster of m6idn.32xlarge instances — no matter how much money you offer the bear.</p><p>You have options when it comes to security controls, and you should have layers. CDN design often means you can shift those choices around — e.g., enforcing content authenticity verification at the client while removing or reducing the scope of File Integrity Monitoring on the server.</p><p>1b. Caching Problems: What happens if there's a time when you really *really* need that cached file or value to expire, and...it doesn't? Can you imagine situations where you *urgently* want a piece of content to be unavailable to anyone or anything that might request it? Let your imagination run wild: stolen keys or certificates, malicious JavaScript, installation bundles with vulnerable packages, inappropriate images... Maybe including this in security wasn't a bizarre idea after all, eh?</p><p>1c. Reliability: The obvious one.</p><p>1d. I...don't recall what I was thinking here. There's some fluid tradeoffs around elasticity, capacity, steering, client switchaway, load balancing, failover, and disaster recovery, so it all blends together.</p><p>Disaster recovery is a common security and reliability paradigm — but let's address that aspect later, along with data security.</p><p>Think in terms of what can go wrong on a CDN. Could an attacker intentionally trigger client switchaway, or bad choices around steering or load balancing? Maybe to a spoofed or compromised server controlled by an attacker?</p>"
},
"attachment": [],
"tag": [],
"replies": {
"id": "https://infosec.exchange/users/saraislet/statuses/109431836960949104/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://infosec.exchange/users/saraislet/statuses/109431836960949104/replies?min_id=109431962277446764&page=true",
"partOf": "https://infosec.exchange/users/saraislet/statuses/109431836960949104/replies",
"items": [
"https://infosec.exchange/users/saraislet/statuses/109431962277446764"
]
}
},
"likes": {
"id": "https://infosec.exchange/users/saraislet/statuses/109431836960949104/likes",
"type": "Collection",
"totalItems": 12
},
"shares": {
"id": "https://infosec.exchange/users/saraislet/statuses/109431836960949104/shares",
"type": "Collection",
"totalItems": 0
}
}
]
}
}