vs做网站不用建项目,网站做好了怎么做后台,大型广告公司有哪些,网站专题制作流程在Coursera安全性最高项目的验尸讨论中提出了一个疯狂的想法。 类可以在序列化期间对其自身进行加密吗#xff1f; 这主要是一项学术性的“假设”练习。 很难想到这样一种情况#xff0c;我们希望在持久性期间依靠对象自加密而不是使用显式加密机制。 我只能确定一种情况 这主要是一项学术性的“假设”练习。 很难想到这样一种情况我们希望在持久性期间依靠对象自加密而不是使用显式加密机制。 我只能确定一种情况我们不能简单地使类无法序列化 HTTPSession钝化 Appserver可以钝化不活动的HTTPSession以节省空间或将会话从一台服务器迁移到另一台服务器。 这就是会话应该只包含可序列化对象的原因。 在可以安装在单个服务器上的小型应用程序中通常会忽略此限制但是如果需要扩展或扩展实现则会导致问题。 一种方法也是首选方法是使会话在钝化过程中将其自身写入数据库并在激活过程中将其自身重新加载。 实际保留的唯一信息是重新加载数据所需的内容通常只是用户ID。 这给HTTPSession实现增加了一些复杂性但是有很多好处。 一个主要好处是确保敏感信息被加密很简单。 这不是唯一的方法某些站点可能更喜欢使用标准序列化。 一些应用服务器可能会将“实时”会话的序列化副本的副本保留在H2等嵌入式数据库中。 谨慎的开发人员可能希望确保敏感信息在序列化期间进行加密即使它永远不会发生。 注意可以提出一个强烈的论点即敏感信息不应该首先出现在会话中–仅在必要时检索它并在不再需要时安全地丢弃它。 该方法 我采用的方法基于有效Java中的序列化一章。 广义上讲我们希望使用序列化代理来处理实际的加密。 该行为是 行动 方法 受保护的序列化类 序列化代理 序列化 writeReplace 创建代理 不适用 writeObject 抛出异常 将加密的内容写入ObjectOutputStream 反序列化 readObject 从ObjectInputStream读取加密的内容 readResolve 构造受保护的类对象 调用反序列化方法时受保护的类引发异常的原因是它防止了攻击者生成的序列化对象的攻击。 请参阅上述书籍中有关虚假字节流攻击和内部字段盗窃攻击的讨论。 这种方法有很大的局限性-如果没有子类重新实现代理则无法扩展该类。 我认为这不是实际问题因为该技术仅用于保护包含敏感信息的类并且很少希望添加超出设计人员期望的方法的方法。 代理类处理加密。 下面的实现显示了使用随机盐IV和加密强消息摘要HMAC来检测篡改。 编码 public class ProtectedSecret implements Serializable {private static final long serialVersionUID 1L;private final String secret;/*** Constructor.* * param secret*/public ProtectedSecret(final String secret) {this.secret secret;}/*** Accessor*/public String getSecret() {return secret;}/*** Replace the object being serialized with a proxy.* * return*/private Object writeReplace() {return new SimpleProtectedSecretProxy(this);}/*** Serialize object. We throw an exception since this method should never be* called - the standard serialization engine will serialize the proxy* returned by writeReplace(). Anyone calling this method directly is* probably up to no good.* * param stream* return* throws InvalidObjectException*/private void writeObject(ObjectOutputStream stream) throws InvalidObjectException {throw new InvalidObjectException(Proxy required);}/*** Deserialize object. We throw an exception since this method should never* be called - the standard serialization engine will create serialized* proxies instead. Anyone calling this method directly is probably up to no* good and using a manually constructed serialized object.* * param stream* return* throws InvalidObjectException*/private void readObject(ObjectInputStream stream) throws InvalidObjectException {throw new InvalidObjectException(Proxy required);}/*** Serializable proxy for our protected class. The encryption code is based* on https://gist.github.com/mping/3899247.*/private static class SimpleProtectedSecretProxy implements Serializable {private static final long serialVersionUID 1L;private String secret;private static final String CIPHER_ALGORITHM AES/CBC/PKCS5Padding;private static final String HMAC_ALGORITHM HmacSHA256;private static transient SecretKeySpec cipherKey;private static transient SecretKeySpec hmacKey;static {// these keys can be read from the environment, the filesystem, etc.final byte[] aes_key d2cb415e067c7b13.getBytes();final byte[] hmac_key d6cfaad283353507.getBytes();try {cipherKey new SecretKeySpec(aes_key, AES);hmacKey new SecretKeySpec(hmac_key, HMAC_ALGORITHM);} catch (Exception e) {throw new ExceptionInInitializerError(e);}}/*** Constructor.* * param protectedSecret*/SimpleProtectedSecretProxy(ProtectedSecret protectedSecret) {this.secret protectedSecret.secret;}/*** Write encrypted object to serialization stream.* * param s* throws IOException*/private void writeObject(ObjectOutputStream s) throws IOException {s.defaultWriteObject();try {Cipher encrypt Cipher.getInstance(CIPHER_ALGORITHM);encrypt.init(Cipher.ENCRYPT_MODE, cipherKey);byte[] ciphertext encrypt.doFinal(secret.getBytes(UTF-8));byte[] iv encrypt.getIV();Mac mac Mac.getInstance(HMAC_ALGORITHM);mac.init(hmacKey);mac.update(iv);byte[] hmac mac.doFinal(ciphertext);// TBD: write algorithm id...s.writeInt(iv.length);s.write(iv);s.writeInt(ciphertext.length);s.write(ciphertext);s.writeInt(hmac.length);s.write(hmac);} catch (Exception e) {throw new InvalidObjectException(unable to encrypt value);}}/*** Read encrypted object from serialization stream.* * param s* throws InvalidObjectException*/private void readObject(ObjectInputStream s) throws ClassNotFoundException, IOException, InvalidObjectException {s.defaultReadObject();try {// TBD: read algorithm id...byte[] iv new byte[s.readInt()];s.read(iv);byte[] ciphertext new byte[s.readInt()];s.read(ciphertext);byte[] hmac new byte[s.readInt()];s.read(hmac);// verify HMACMac mac Mac.getInstance(HMAC_ALGORITHM);mac.init(hmacKey);mac.update(iv);byte[] signature mac.doFinal(ciphertext);// verify HMACif (!Arrays.equals(hmac, signature)) {throw new InvalidObjectException(unable to decrypt value);}// decrypt dataCipher decrypt Cipher.getInstance(CIPHER_ALGORITHM);decrypt.init(Cipher.DECRYPT_MODE, cipherKey, new IvParameterSpec(iv));byte[] data decrypt.doFinal(ciphertext);secret new String(data, UTF-8);} catch (Exception e) {throw new InvalidObjectException(unable to decrypt value);}}/*** Return protected object.* * return*/private Object readResolve() {return new ProtectedSecret(secret);}}
} 毋庸置疑加密密钥不应如图所示进行硬编码或缓存。 这是一条捷径让我们可以专注于实施的细节。 密码和消息摘要应使用不同的密钥。 如果使用相同的密钥则将严重损害系统的安全性。 任何生产系统都应处理另外两件事密钥轮换以及更改密码和摘要算法。 前者可以通过在有效负载中添加“密钥ID”来处理后者可以通过绑定序列化版本号和密码算法来处理。 例如版本1使用标准AES版本2使用AES-256。 解串器应该能够处理旧的加密密钥和密码在合理范围内。 测试码 测试代码很简单。 它创建一个对象对其进行序列化反序列化然后将结果与原始值进行比较。 public class ProtectedSecretTest {/*** Test happy path.*/Testpublic void testCipher() throws IOException, ClassNotFoundException {ProtectedSecret secret1 new ProtectedSecret(password);ProtectedSecret secret2;byte[] ser;// serialize objecttry (ByteArrayOutputStream baos new ByteArrayOutputStream();ObjectOutput output new ObjectOutputStream(baos)) {output.writeObject(secret1);output.flush();ser baos.toByteArray();}// deserialize object.try (ByteArrayInputStream bais new ByteArrayInputStream(ser); ObjectInput input new ObjectInputStream(bais)) {secret2 (ProtectedSecret) input.readObject();}// compare values.assertEquals(secret1.getSecret(), secret2.getSecret());}/*** Test deserialization after a single bit is flipped.*/Test(expected InvalidObjectException.class)public void testCipherAltered() throws IOException, ClassNotFoundException {ProtectedSecret secret1 new ProtectedSecret(password);ProtectedSecret secret2;byte[] ser;// serialize objecttry (ByteArrayOutputStream baos new ByteArrayOutputStream();ObjectOutput output new ObjectOutputStream(baos)) {output.writeObject(secret1);output.flush();ser baos.toByteArray();}// corrupt ciphertextser[ser.length - 16 - 1 - 3] ^ 1;// deserialize object.try (ByteArrayInputStream bais new ByteArrayInputStream(ser); ObjectInput input new ObjectInputStream(bais)) {secret2 (ProtectedSecret) input.readObject();}// compare values.assertEquals(secret1.getSecret(), secret2.getSecret());}
}最后的话 我不能过分强调–这主要是一种智力活动。 像往常一样最大的问题是密钥管理而不是加密并且通过前者所需的工作水平您可能可以更快地实现更传统的解决方案。 在某些情况下这可能仍然“足够好”。 例如您可能只需要在长时间运行的应用程序期间保留数据。 在这种情况下您可以在启动时创建随机密钥并在程序结束后直接丢弃所有序列化的数据。 源代码 https : //gist.github.com/beargiles/90182af6f332830a2e0e 翻译自: https://www.javacodegeeks.com/2015/06/auto-encrypting-serializable-classes.html
